Peter Jeremy peterjeremy at
Wed Sep 7 11:37:12 UTC 2011

On 2011-Sep-06 23:30:04 -0700, Stanislav Sedov <stas at> wrote:
>What about requiring that the ports deprecated should be either broken
>or have known published vulnerabilties for a long period of
>time (say 6 months) for the start?

This might be reasonable for broken ports but ports with known
vulnerabilities should either be fixed or removed promptly.

>  Personally, I'd also love to see
>people deprecating ports provide a clear reasoning for deprecation in
>the commit message (not just "deprecated some old ports" etc), so one
>won't need to guess if he would like to fix/resurrect the port in the

This is a reasonable requirement.

On 2011-Sep-07 01:35:54 -0600, Chad Perrin <code at> wrote:
>One thing I've seen come up that I definitely think would be a good idea,
>though, is more accessible documentation of the CVS "attic", though.  I
>had no idea such a thing existed for old FreeBSD ports until fairly
>recently, and still don't know much about it.

Any VCS worthy of the name will retain history for objects that no
longer exist because you might want to look at the state as it was at
some point in the past when that object still existed.  CVS stores the
RCS masters for these deleted files is a subdirectory 'Attic' under
the original directory.  The data is only accessible via CVS - either
using a local repository or via CVSweb.  As an example, look at:

>  I would think that the
>porter's handbook, at least, should mention it (perhaps with a brief
>explanation of why and how one might make use of it).

Again, it comes down to someone with the knowledge, motivation and
time to write the content.

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

>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.

>  The
>proposal is to increase the liklihood that, come upgrade time,
>a "release user" gets a specific, actionable description of
>any problems that have arisen, rather than having a port that
>they have been using mysteriously disappear.

Again, ports don't "mysteriously disappear" - there will be a
record of why it was removed in the MOVED file.

>Last I checked, was claiming that the very large number
>of supported ports was a feature.  It seems that some of the ports
>committers disagree.

Cleaning out the cruft will still leave a very large number of ports.
And a better selling point is having a large number of functional
ports - having a ports tree full of ports that are broken doesn't
benefit anyone.

>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

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.
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.

Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url :

More information about the freebsd-ports mailing list