Date: Thu, 08 Sep 2011 03:28:31 +0200 From: "Julian H. Stacey" <jhs@berklix.com> To: ports@FreeBSD.org Cc: Doug Barton <dougb@FreeBSD.org>, perryh@pluto.rain.com, utisoft@gmail.com Subject: Re: sysutils/cfs Message-ID: <201109080128.p881SVZF021424@fire.js.berklix.net> In-Reply-To: Your message "Wed, 07 Sep 2011 15:45:51 PDT." <4E67F41F.70401@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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, it gets tagged & goes on cdrom images, packages get rolled. (Yes, Not quite the same as src/ ) cvs -Q -R export -r RELENG_8_2_0_RELEASE src # du=548 M tgz=115 M cvs -Q -R export -r RELEASE_8_2_0 ports # du=475 M tgz= 49 M cvs -Q -R export -r RELEASE_8_2_0 doc # du=100 M tgz= 27 M > that's one of the reasons for the operational > separation of ports and src. > > That said, users are of course welcome to operate in the manner you > describe. They just shouldn't be surprised if they run into problems > doing it that way. > > >> The point has repeatedly been made that with almost 23,000 > >> ports in the tree both innovation and maintenance become > >> significantly more difficult. Keeping that burden as low > >> as possible is a feature. > > > > s/point/claim/ > > Point being made by people actually doing the work. Those who don't like > that answer attempting to refute it as a claim. :) > > > Last I checked, freebsd.org was claiming that the very large number > > of supported ports was a feature. It seems that some of the ports > > committers disagree. > > Non sequitur. The large number of ports that we support IS a feature. > However, it's also a pretty big maintenance burden. Especially when you > consider the number of those ports that are either actually or > effectively unmaintained. Maintaining a high level of actual support for > the ports tree is the goal here. In the near term future we're also > hoping to provide some new, better tools; as well as better/more > consistent package support. In order to do those things we need to make > sure that we're putting our effort where it is most needed. > > > Benefit: see above. Maintenance: I would not think that updating > > NEXT_PORT_PURGE_DATE as required -- a couple of times per release > > cycle, maybe a few more if the schedule slips repeatedly -- would > > constitute a significant additional maintenance burden. > > To put it bluntly, you don't see it because you're not the one doing the > work. > Doug Too much so called Work has been irresponsible damaging Play. Ports butchers should stop, or be stopped. Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below, not above; Indent with "> "; Cumulative like a play script. Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. http://www.softwarefreedomday.org 17th Sept, http://berklix.org/sfd/ Oct.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201109080128.p881SVZF021424>