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

[Michael Gmelin]

On Sat, 28 Dec 2013 23:44:35 -0800
Kevin Oberman <rkoberman at gmail.com> wrote:

> On Thu, Dec 26, 2013 at 12:56 AM, Doug Barton <dougb at dougbarton.us>
> 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 installed.
> 
> 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.

A side note on the iconv change: It seems like most ports have been
changed to use base iconv where available, so the only criterion was ABI
compatibility. The fact that some ports are written for GNU iconv and
not POSIX iconv wasn't taken into account.

The most prominent example is PHP5, converters/php5-iconv to be
precise. Its documentation clearly describes GNU iconv extensions
(TRANSLIT/IGNORE) as core features - it does not qualify "based on
you iconv library", because PHP5 is supposed to be built with GNU
iconv. It was changed nevertheless, so upgrading to 10-RELEASE and
rebuilding PHP5 will break people's code.

I opened ports/184596 a few weeks ago, no response so far:
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/184596

> 
> 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.





-- 
Michael Gmelin