Opened 3 years ago

Closed 3 years ago

#10989 closed enhancement (fixed)

Revert Berkeley DB to version 5.

Reported by: ken@… Owned by: ken@…
Priority: normal Milestone: 8.3
Component: BOOK Version: SVN
Severity: normal Keywords:


Reasons at

Let's give people an opportunity to disagree (if they want to), or to explain why this might be a bad idea - AFAICS, once it builds, every linux package which can use it should already known the details of version 5.

Change History (10)

comment:1 by ken@…, 3 years ago

Owner: changed from blfs-book to ken@…
Status: newassigned

comment:2 by ken@…, 3 years ago

A note on source locations: Oracle needs a login to allow you to download. I've found the following, among others - seems to be a French mirror for 0linux freenas fedora, but URL is unmanageably long FreeBSD ports UK public mirror, at University of Kent, for macports

All have an md5sum of b99454564d5b4479750567031d66fe24

comment:3 by thomas, 3 years ago

As a first and spontan reaction, i'll agree to revert. I do not have any technical arguments about pro and cons but what i know that there are some packages which check on "older" version like 4 or 5 (or 6) which might need to be patched to see the new version. v5 seems to be somewhat rocksolid (otherwise other distros wouldn't stay on it) and its ok for LFS to use solid versions instead of bleeding-edges. If revert makes life easier for us, fine!

IMHO, not supporting download sites which requires a login is opportune; free software has to be free, without grabbing tons of marketing data.

Btw, has 5.3.28 too. Also

Last edited 3 years ago by thomas (previous) (diff)

comment:4 by Bruce Dubbs, 3 years ago

How about hosting version 5 on anduin? It's not like it is large (34M) or will change.

in reply to:  4 comment:5 by ken@…, 3 years ago

Replying to bdubbs:

How about hosting version 5 on anduin? It's not like it is large (34M) or will change.

Sounds good.

Without any alterations, it looks as if current c++ breaks it. Lots of warnings about conflicting type for atomic_compare (something) scrolled past (not logged) then

In file included from ../src/dbinc/mutex_int.h:12,
                 from ../src/dbinc/mutex.h:15,
                 from ./db_int.h:1113,
                 from ../lang/cxx/cxx_channel.cpp:11:
../src/dbinc/atomic.h:179:19: error: definition of ‘int __atomic_compare_exchange(db_atomic_t*, atomic_value_t, atomic_value_t)’ ambiguates built-in declaration ‘bool __atomic_compare_exchange(long unsigned int, volatile void*, void*, void*, int, int)’
 static inline int __atomic_compare_exchange(
make: *** [Makefile:2417: cxx_channel.lo] Error 1

Arch have a patch 'atomic.patch' to fix that, we can do the same with

sed -i 's/\(__atomic_compare_exchange\)/\1_db/' src/dbinc/atomic.h

and that builds and DESTDIRs : I'm not going to downgrade my running system, or test bogofilter or evolution-data-server here and anyway this is still glibc-2.27, but looking ok.

Assuming that I'm able to look at this in about a week's time (experimental build, glibc-2.28 plus icu, poppler), I will test the db part of those two (but probably trying to work around recommended deps for e-d-s).

For php, the comment can go.

For openldap, versions of DB >= 6 have a license incompatability according to upstream. They said that DB-5 is ok but deprecated, so change the comment to 'deprecated'.

comment:6 by ken@…, 3 years ago

source uploaded to my public_html directory at anduin

comment:7 by Bruce Dubbs, 3 years ago

Last edited 3 years ago by Bruce Dubbs (previous) (diff)

comment:8 by ken@…, 3 years ago

I'm (still) looking at trying to reinstate the tests (Andy commented them in r10369 when moving to 5.3.21). Failures in comparing after bulk delete or in checking that a transaction had been applied. Also, despite only 5 jobs, it used up to 800% of an 8-core machine.

First attempt to remove failures by using a lower number of parallel jobs did not work. In the output from running (but not in the logs) there are comments about db_repsite not being built, and I wonder if those messages are for the tests which fail. This time I used taskset to restrict to 4 cores so I could do other things, loadavg often around 7 when other cores idle. But many tests barely load the machine, this is more time-based than SBU-based.

According to gentoo, upstream strip the db_repsite sources (confirmed - mentioned in Makefile but not present) and they have a sed to remove them. They also have one other sed for a false positive - but let's see if I can get to that few errors.

comment:9 by ken@…, 3 years ago

Didn't help. Will leave everything related to tests commented out.

comment:10 by ken@…, 3 years ago

Resolution: fixed
Status: assignedclosed
Note: See TracTickets for help on using tickets.