Berkeley DB cleanup has apparently broken ports where no db is currently installed

Kevin Oberman rkoberman at
Sun Dec 29 07:44:36 UTC 2013

On Thu, Dec 26, 2013 at 12:56 AM, Doug Barton <dougb at> wrote:

> On 12/26/2013 12:41 AM, Matthias Andree wrote:
>> I disagree on the assessments of efforts here. I checked the docs,
>> and the actual .db files are supposed to be compatible,
> Sure, they are, to some extent, SUPPOSED to be compatible. Experience
> tells us that is not the case.
>  excepting the
>> corner cases mentioned in the wiki. The manual effort only exists for
>> ports using BDB in transactional mode, while most ports just use it
>> as a key-value data vault.
> So you're volunteering to walk every user whose stuff gets broken through
> the repair?
>  Ttbomk, deprecated does not cause build failures, and even if so,
>> WITH_BDB_VER=5 would fix that.
> portmaster treats DEPRECATED as a fatal error. I did neglect to point that
> out in my previous post however.
>  Finally, I would like to see technical or other_compelling_  reasons
>> why we would need 48 in the tree in the future.
> Well shouldn't that argument go the other way around? Shouldn't the people
> proposing the purge be the ones to provide _compelling_ reasons to do the
> purge?
> Doug

I updated from 9-Stable to 10.0-RC3 dy before yesterday. I had one odd
error during the upgrade, but  managed to complete the upgrade. Then I
re-built all ports. I had a few issues, all resolved except one that i have
opened a PR for, but I did have a very annoying time with Berkeley DB.

I had deleted all ports, so I assumed that port requiring Berkeley DB would
use db5 or db6. But, as Doug noted, no such luck. As Doug pointed out, this
is because some ports require db4x. Specifically,
databases/evolution-data-server required db41. No option for any newer
version. apr1 required db42+, but that just pulls in db4* forts, so no db5
gets installed, even though the port clearly stats that it works with 5. So
4.2+ really means any db4. version.

There is no reason that ports using "USE_BDB=4.\+ could not have been found
(by a simple grep) and been "fixed" to use db5 (assuming that they really
do work with db5), but they were not. Or the Mk files could have caused the
cases where db4.\+ were called for that this could not have installed db5
or even db6 rather than insist on db4. (And, quite oddly, the LOWEST db4
version that allowed was the one installed when no matching db was

Rather than mess around with fixing multiple Makefiles while my system was
unable to do much of anything, I just removed the DEPRECATED lines form
db41, db42, and db43. I'll need to go clean them all up, now. And some
don't even make it clear that they will run with db5.  And I still have
seen no reason that the db4 ports really needed removal. They still work
fine and are widely used. Deprecation was just asking for trouble. (Don't
forget that a "DEPRECATED" statement in a port Makefile is fatal.)

I will also mention that the man page for portmaster REALLY needs to be
updated for pkgng. This wasted just a bit more of my time. Due to the iconv
move to base, the "quick and dirty" rebuild option of "portmaster -aD"
fails miserably. I suspect portupgrade would have a similar problem, but I
have not used it in a couple of years, so I can't be sure.

On the whole, I have to call this one a really botched change that should
be rolled back until it can be implemented to work properly, at least for a
clean install of all ports.
R. Kevin Oberman, Network Engineer
E-mail: rkoberman at

More information about the freebsd-ports mailing list