ports deprecations (was: sysutils/cfs)

[Matthias Andree]

Am 10.09.2011 07:45, schrieb Conrad J. Sabatier:

>>> Frankly, I'm growing increasingly concerned that this push to
>>> eliminate ports is getting out of control.  I don't much care for
>>> the notion that, having invested the time in installing,
>>> configuring and tuning a certain set of software packages, suddenly
>>> the rug could be pulled out from under me, so to speak, in essence
>>> *forcing* me to abandon using certain packages or else deal with
>>> maintaining them (in the ports maintainer sense) on my own.
>>
>> The rug is pulled by the upstream maintainers abandoning their
>> software, not by FreeBSD no longer packaging it years after the fact.
> 
> While I understand the reasoning behind this, I still feel that as long
> as a package continues to build and run without any known issues, then
> why be in a rush to drop it?  The argument that "the ports collection
> is not a museum" is valid to some degree, but if a package is still
> usable (and useful), then aren't we shooting ourselves in the foot by
> dropping it?

Conrad,

(courtesy Cc: after changed subject, please reply to the list)

I'd see that as proactive maintenance.

If there is no upstream maintainer any more, chances is that one time
the port needs code changes to adapt to changes in underlying libraries.

For the sake of argument, let's assume this example (I'm not sure if
libpng would be a real-world instance of it, I didn't care enough to
have a closer look):

There are points in time when dead port X using a changed library Y
needs code changes, for instance, if library Y in some old unmaintained
version is vulnerable, and its fixed versions have a different API.

Now, if we tell people soon enough that they may run into that problem,
chances are that people never hit the problem, and
chances are that people hit the problem soon - and the fewer users of
the dead port are forced to make the switch, the better.

The open question is, is there a point in marking a point DEPRECATED
without giving an expiration date.  My personal answer is "no" because
no-one will believe in a DEPRECATED tag without EXPIRATION_DATE and
people will be disappointed because they've grown used to custom and
practice and I can already see the "we told you it was DEPRECATED".

The real point is that the FreeBSD ports system can not fill in for the
maintainers of discontinued ports.

There is a certain pragmatism to "as long as it builds, appears to work,
and there are no known critical bugs, let's keep it", but it has this
organizational drawback that it becomes custom and practice at some
time, and ends up hurting more people in the end.

Best regards,
Matthias