Julian H. Stacey
jhs at berklix.com
Thu Sep 8 01:29:17 UTC 2011
> 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, 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
Too much so called Work has been irresponsible damaging Play.
Ports butchers should stop, or be stopped.
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.
More information about the freebsd-ports