sysutils/cfs

[perryh at pluto.rain.com]

Peter Jeremy <peterjeremy at acm.org> wrote:

> On 2011-Sep-07 10:02:42 -0700, perryh at 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).