Revert Berkeley DB to version 5.

[ken@…]

Reasons at ​http://lists.linuxfromscratch.org/pipermail/blfs-dev/2018-August/034672.html

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.

[ken@…]

A note on source locations: Oracle needs a login to allow you to download. I've found the following, among others -

​http://ftp.lip6.fr/pub/linux/distributions/0linux/archives_sources/berkeley-db/ seems to be a French mirror for 0linux

​https://download.freenas.org/distfiles/bdb/ freenas

​https://src.fedoraproject.org/lookaside/pkgs/libdb/db-5.3.28.tar.gz/b99454564d5b4479750567031d66fe24/ fedora, but URL is unmanageably long

​http://distfiles.icmpv6.org/distfiles/bdb/ FreeBSD ports

​http://www.mirrorservice.org/sites/distfiles.macports.org/db53/ UK public mirror, at University of Kent, for macports

All have an md5sum of b99454564d5b4479750567031d66fe24

[thomas]

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, ​http://ftp.icm.edu.pl/pub/unix/database/db/ has 5.3.28 too. Also ​https://sources.voidlinux.eu/db-5.3.28/

[Bruce Dubbs]

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

[ken@…]

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

[ken@…]

source uploaded to my public_html directory at anduin

[Bruce Dubbs]

I made it available at ​http://anduin.linuxfromscratch.org/BLFS/bdb/db-5.3.28.tar.gz

[ken@…]

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.

[ken@…]

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

[ken@…]

r20323