saving a few ports from death

Mikhail T. mi+thun at
Wed Apr 27 20:04:01 UTC 2011

On 27.04.2011 14:16, Eitan Adler wrote:
> Then bapt@ marked the ports*deprecated*  which does not mean deleted. It was a warning that people who were interested should step up and take up the work. If after N amount of time no one does so they will be individually deleted.
The ports I listed -- db2 and apache13* family -- are/were not broken. What 
"work" are you talking about?

Yet, mandree deleted db2 on April 12th and dougb is anxious to delete apache13 
as well instead of simply disowning it...
>> >  Maybe, for cleanliness and neatness, we should have a separate directory
>> >  (and category): "obsolete" -- where ports can go to die peacefully. But it
>> >  should not be cvs' "Attic"...
> Who will be the ones to deal with that category, ensuring new
> infrastructure works, etc? The port maintainer? oh wait!
The same entity(ies), that currently busy themselves marking things 
"deprecated". But it was just a proposal -- for those, who don't like to see 
"obsolete" software mixed with the latest and greatest. I'm perfectly satisfied 
with not touching "obsolete" things at all. Certainly not until they break -- 
and stay broken for "too long".
> cvs's Attic can be easily restored if people take up the slack. I see
> no reason to change this policy
No, not easily. It requires the CVS tree, which is not automatically installed. 
/usr/ports/obsoleted, on the other hand, would be rolled out together with the 
rest of the ports-tree. And, under my proposal, the packages for the "obsolete" 
stuff will continue building.

The "if people take up the slack" seems to imply need to continuously work on 
the software. But the db2 needed no serious changes since 2004 and the last 
meaningful change was in 2008... The only reason to kill it was "too old"... Now 
all current users of db2 have to move onto later dbX, which means not only 
patching up the API-calls in their source-code (if the source code is even 
available!), but recreating their databases too -- because Berkeley DB files are 
not backwards-compatible. And for what reason?..

Same goes for apache13 -- last change was an upgrade to 1.3.42 (February 2010) 
-- it does not seem to require much work. There may well be good reasons to hate 
it, but somebody with a custom module, for example, may be perfectly satisfied 
with it... I happen to know one such site, for example. There may be more. If 
apache@ does not want it, they can drop maintainership. But deletion is not 
called for.

Upgrading the OS should not /require/ upgrading (and replacing!) the applications.



More information about the freebsd-ports mailing list