Date: Wed, 07 Sep 2011 22:07:12 -0700 From: perryh@pluto.rain.com To: peterjeremy@acm.org Cc: ports@freebsd.org Subject: Re: sysutils/cfs Message-ID: <4e684d80.Tqcv8N/ULmPVDa5w%perryh@pluto.rain.com> In-Reply-To: <20110907113707.GA30349@server.vk2pj.dyndns.org> References: <201109050933.p859XEbP004874@fire.js.berklix.net> <4E64C35A.50004@FreeBSD.org> <4e65b42e.M5K%2Bto11vAdk/UTk%perryh@pluto.rain.com> <4E6581E2.1060502@FreeBSD.org> <4e671817.ddHMkPbq9dJ7tLMz%perryh@pluto.rain.com> <4E66EFC5.3020201@FreeBSD.org> <4e67a3b2.CVKcpQ8KQzuo8BP%2B%perryh@pluto.rain.com> <20110907113707.GA30349@server.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Jeremy <peterjeremy@acm.org> wrote: > On 2011-Sep-07 10:02:42 -0700, perryh@pluto.rain.com wrote: > >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. > ... > >In contrast, if the port is > >_no longer_ in the tree, they have no clue why it disappeared. > > This last statement isn't true - when a port is moved or removed, > a one-line reason for the change is added to /usr/ports/MOVED > The package management tools are generally aware of this file. Unfortunately, the information quality of those lines is highly variable. Absent elaboration, entries like "no longer needed", "obsolete", "removed deprecated port", or "security vulnerability" are not actionable: they don't identify what would need to be done to restore the now-missing functionality. > >It's only going to be removed if no one fixes it. 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). > > This isn't necessarily a wise approach. It may not be wise, but I suspect it is widespread (and based on the discussion I think that Julian and several others would agree). I agree with Doug that we need to "provide the best support possible for the largest percentage of our users." One problem in doing so is that, absent hard data, one guess is as good as another WRT to how often "the largest percentage of our users" check for issues in their installed ports. My guess is that "the largest percentage of our users" currently do _not_ monitor port vulnerabilities on an ongoing basis, and I would not expect this situation to change until * portaudit has been made a dependency of the infrastructure and enabled by default, and * there has subsequently been a release cycle on each supported branch. At that point I would think it reasonable to presume that most newly-installed or -updated systems _will_ be running portaudit if they are using ports or packages. > >So define a variable along the lines of NEXT_PORT_PURGE_DATE > >in one of the /usr/share/mk/bsd.port*.mk files, which (being > >part of the base) _are_ branched, and when a situation of the > >kind under discussion arises set the port's EXPIRATION_DATE > >to NEXT_PORT_PURGE_DATE. > > Two issues: > 1) Since the ports tree isn't branched and a port either exists > or it doesn't exist, there needs to be a single expiration date. My idea with NEXT_PORT_PURGE_DATE was that the port Makefile would specify "EXPIRATION_DATE=$(NEXT_PORT_PURGE_DATE) so that the _advertised_ expiration date would vary depending on which base branch was in use, but that's needlessly complicated. Much simpler would be to maintain a list of the next anticipated release date for each supported branch -- I think we already have this somewhere on freebsd.org, although it is not always as up-to-date as might be desired -- and ask ports committers to consult that list and set EXPIRATION_DATE to, say, 3 months past the last "next release". (3 months would allow for a month's slippage in the release, and still leave 2 months between release and expiration.) Another variant would be to provide that set of dates somewhere in /usr/ports/Mk, as (say) REL_74_PURGE_DATE, REL_83_PURGE_DATE, etc. so the committer only has to choose the latest of them and put EXPIRATION_DATE=$(REL_83_PURGE_DATE) -- or whatever -- in the Makefile. That would allow for centralized updating to account for release slips. > 2) There still needs to be a minimum expiration duration so you > need a way to handle the case where a port is marked "to be > purged" immediately before the NEXT_PORT_PURGE_DATE. The above takes care of this also. In the last variant, if the latest REL_xx_PURGE_DATE is too soon, it almost certainly means that the list is out of date and needs a new entry added (for a release that will be subsequent to any currently listed).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4e684d80.Tqcv8N/ULmPVDa5w%perryh>