sysutils/cfs
Julian H. Stacey
jhs at berklix.com
Thu Sep 8 01:29:17 UTC 2011
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, 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.
More information about the freebsd-ports
mailing list