sysutils/cfs

[Chris Rees]

On 8 Sep 2011 02:29, "Julian H. Stacey" <jhs at berklix.com> wrote:
>
> Hi,
> Reference:
> > From:         Doug Barton <dougb at FreeBSD.org>
> > Date:         Wed, 07 Sep 2011 15:45:51 -0700
> > Message-id:   <4E67F41F.70401 at FreeBSD.org>
>
> Doug Barton wrote:
> > On 9/7/2011 10:02 AM, perryh at pluto.rain.com wrote:
> > > Doug Barton <dougb at freebsd.org> wrote:
> > >> On 09/07/2011 00:07, perryh at pluto.rain.com wrote:
> > >>> Doug Barton <dougb at freebsd.org> wrote:
> > >>>>>>>>> Better to deprecate such non urgent ports, & wait a while
> > >>>>>>>>> after next release is rolled, to give release users a warning
> > >>>>>>>>> & some time to volunteer ...
> > >>>>>>
> > >>>>>> That's an interesting idea, but incredibly unlikely to happen.
> > >>>>>
> > >>>>> It _certainly_ won't happen if those in charge refuse to try it!
> > >>>>
> > >>>> My point was that the idea is impractical ...
> > >>>
> > >>> How is it impractical to, as a rule, set an expiration date based
> > >>> on an anticipated future release date rather than only a month or
> > >>> two out from when the decision is made?
> > >>
> > >> As has repeatedly been explained to you ...
> > >
> > > I think you may have gotten me confused with someone else.
> >
> > Quite possibly. :)  Saying the same things over and over again gets
> > mentally exhausting after a while.
> >
> > >> you're asking the wrong question. The question is, how does it
> > >> benefit the users to leave it in when we know that we're going
> > >> to delete it?  Either way the user will discover that the port
> > >> is not easily available for installation when they update their
> > >> ports tree.
> > >
> > > Reread the first paragraph.  Provided the port is still in the
> > > tree, when they try to build it the ports mechanism reports the
> > > FORBIDDEN/BROKEN/whatever which describes the problem, and the
> > > expiration date a month or two out.  (If the expiration date is
> > > not included in the report, it should be.)  They then know that
> > > they need to fix the port, or find someone to fix it, and they
> > > know _why_ it needs to be fixed.  In contrast, if the port is
> > > _no longer_ in the tree, they have no clue why it disappeared.
> >
> > As was pointed out elsewhere in the thread, the MOVED entry should
> > contain that information. Generally what I do when I actually remove a
> > port is to copy the DEPRECATED/FORBIDDEN message into the MOVED file
entry.
> >
> > However, even if that isn't sufficient the entire story is still
> > available in the CVS history. And the user can always ask on
> > freebsd-ports@ if they are really confused and need help.
> >
> > >> The difference is that in the meantime people doing work on
> > >> the ports tree don't have to work around the old port (that's
> > >> going to be removed anyway).
> > >
> > > It's only going to be removed if no one fixes it.
> >
> > .. which is what happens in the vast majority of cases.
> >
> > > The whole
> > > point is that "release users" don't continuously monitor their
> > > ports -- they only upgrade when they become aware that they
> > > need to (e.g. when a newer release becomes available).
> >
> > And what we have been trying to explain to you is that this has never
> > been a supported mode of operation. We don't tie the ports tree to
> > specific releases,
>
> [ I've been reading & not writing , as real life priorities intrude,
> but that phrase has been repeated too often to ignore ...]
>
> FreeBSD doese "tie the ports tree to specific releases".  We have ports
> freezes before each release

We don't, actually.