Date: Thu, 8 Sep 2011 07:20:27 +0100 From: Chris Rees <utisoft@gmail.com> To: "Julian H. Stacey" <jhs@berklix.com> Cc: ports@freebsd.org, Doug Barton <dougb@freebsd.org>, perryh@pluto.rain.com Subject: Re: sysutils/cfs Message-ID: <CADLo83-4Hbq%2BCe5ADJvEQP7167wJt48C8aOfCW8RV=W96stMCw@mail.gmail.com> In-Reply-To: <201109080128.p881SVZF021424@fire.js.berklix.net> References: <4E67F41F.70401@FreeBSD.org> <201109080128.p881SVZF021424@fire.js.berklix.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 8 Sep 2011 02:29, "Julian H. Stacey" <jhs@berklix.com> wrote: > > Hi, > Reference: > > From: Doug Barton <dougb@FreeBSD.org> > > Date: Wed, 07 Sep 2011 15:45:51 -0700 > > Message-id: <4E67F41F.70401@FreeBSD.org> > > Doug Barton wrote: > > On 9/7/2011 10:02 AM, perryh@pluto.rain.com wrote: > > > Doug Barton <dougb@freebsd.org> wrote: > > >> On 09/07/2011 00:07, perryh@pluto.rain.com wrote: > > >>> Doug Barton <dougb@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADLo83-4Hbq%2BCe5ADJvEQP7167wJt48C8aOfCW8RV=W96stMCw>