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.
Yours,
-mi
_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
