Overly aggressive obsoleting of ports (Re: FreeBSD ports which are currently scheduled for deletion)

Mikhail T. mi+thun at aldan.algebra.com
Sat Nov 22 23:50:44 UTC 2014

On 22.11.2014 18:19, Kevin Oberman wrote:
> It's not like FreeBSD has a to of choice when the  BerkeleyDB folks
> have dropped  db-4.8.
I don't see a connection... People getting their software from Oracle
may have a point to make with the vendor. I'm talking about those, who
install it via FreeBSD port. Nor do I see, what you mean by "have
dropped" -- certainly, the manual is still there:


As is the tarball. More generally, I do not believe, our decision to
drop a particular package should be based on that of the software's
authors/vendors -- unless their license requires us to, of course.

Sure, it usually makes little sense to keep a port of foo-X, when
foo-(X+1) is available. But some software groups -- like BerkeleyDB or
KDE -- have historically been obnoxiously bad about compatibility with
their own older releases. In these situations, FreeBSD ought to keep it
easy for our users to stay with the old version for much longer, than we
have been doing lately...
> It's been obsolete for a very long time.
db-4.8.30 was released in 2010. That is not "a very long time" ago. Not
at all. Even if it were declared "obsolete" back then -- which it was not...
> You just need to re-install them.
What of the organizations' own projects, which rely on BerkeleyDB? Even
if they do all continue to work after changing, verifying it takes time.
Worse, major upgrades of BerkeleyDB require migrating the data. It is
not a trivial task some times -- especially with large databases (such
as an LDAP user-database of a major company).

Heck, even an Apache-upgrade from 2.4.x to 2.4.y can be a minefield some
times, even when nothing was /supposed/ to have changed. With
BerkeleyDB, coming up with upgrade instructions and the scripts for
dump-ing and restore-ing of existing databases -- required planning and
man-days of development, testing, and roll-out efforts. Suggesting, such
efforts must be undertaken immediately -- on a whim of our portmgr@ team
-- is simply a non-starter.

Do you want to tell companies using FreeBSD, that ports/ can not be
relied on for anything mission-critical? Well, I guess, you might be
right if you said that today, but the goal ought to be to reverse that
unfortunate trend, not to accelerate it...


More information about the freebsd-ports mailing list