[blfs-support] Revert Berkeley DB to v5

[Ken Moffat]

I've now raised ticket
http://wiki.linuxfromscratch.org/blfs/ticket/10989#ticket
for this. I documented the reasons on -dev in
http://wiki.linuxfromscratch.org/blfs/ticket/10989#ticket
but since most users don't read -dev I'll mention it here too.

AFAICS, use of DB version 5 is a known and expected situation, so
the details of what changed internally in a given version do not
need to concern us (unlike any possible changes from v6 to v18).
So, once it builds (Arch apply a patch) it should just drop in and
reduce our maintenance.

But maybe I'm missing something, or perhaps people think that
reverting to an old stable version is generally undesirable. If so,
this is your chance to speak up.

NB - I'm already overdrawn on the time I'm committing to BLFS. All
being well, I'll look at this on my *next* build (that will be
several days away) where I plan to experimentally try newer versions
of some packages to see if htey cause problems.

ĸen

[scrat]

Post by Ken Moffat
I've now raised ticket
http://wiki.linuxfromscratch.org/blfs/ticket/10989#ticket
for this. I documented the reasons on -dev in
http://wiki.linuxfromscratch.org/blfs/ticket/10989#ticket
but since most users don't read -dev I'll mention it here too.
AFAICS, use of DB version 5 is a known and expected situation, so
the details of what changed internally in a given version do not
need to concern us (unlike any possible changes from v6 to v18).
So, once it builds (Arch apply a patch) it should just drop in and
reduce our maintenance.
But maybe I'm missing something, or perhaps people think that
reverting to an old stable version is generally undesirable. If so,
this is your chance to speak up.
NB - I'm already overdrawn on the time I'm committing to BLFS. All
being well, I'll look at this on my *next* build (that will be
several days away) where I plan to experimentally try newer versions
of some packages to see if htey cause problems.
ĸen

I build rpm with Berkeley DB version 6.0.20.  and have not had an issues
for 2 years.
I do not use the Arch linux patch, it builds straight up for me.
What was the issue with version 6?

[Ken Moffat]

Post by Ken Moffat
I've now raised ticket
http://wiki.linuxfromscratch.org/blfs/ticket/10989#ticket
for this. I documented the reasons on -dev in
http://wiki.linuxfromscratch.org/blfs/ticket/10989#ticket
but since most users don't read -dev I'll mention it here too.
AFAICS, use of DB version 5 is a known and expected situation, so
the details of what changed internally in a given version do not
need to concern us (unlike any possible changes from v6 to v18).
So, once it builds (Arch apply a patch) it should just drop in and
reduce our maintenance.
But maybe I'm missing something, or perhaps people think that
reverting to an old stable version is generally undesirable. If so,
this is your chance to speak up.
NB - I'm already overdrawn on the time I'm committing to BLFS. All
being well, I'll look at this on my *next* build (that will be
several days away) where I plan to experimentally try newer versions
of some packages to see if htey cause problems.
ĸen

I build rpm with Berkeley DB version 6.0.20.  and have not had an issues for
2 years.
I do not use the Arch linux patch, it builds straight up for me.
What was the issue with version 6?

The apparent issue is with building version _5_ on current systems.

[Michael Shell]

I don't have a strong opinion on it one way or another, but my vote is to
retain the latest version. Oracle is using a GPL license (AGPL) so
redistribution (i.e. a lack of distribution sites) should not be an issue.
The LWN article expressing concern about the AGPL was written in 2013.

Given the way things work with the FSF, many other projects will eventually
be affected by the AGPL issue anyway. (If the FSF wants all source
code/modifications to be publicly available for all GPL/free software that
has been modified and that provides, or is linked to that which provides,
public web services, then it will evolve the GPL as needed to achieve that
goal world wide.)

Furthermore, recent versions of packages tend to have fewer problems with
recent compilers.

If there were to arise a significant fork or alternative with regard to the
Berkeley DB, or we could not download it from any site without registering
with Oracle, or if we knew that db-18.1.25 or later broke a significant
number things, then I could see some solid grounds for reverting to an
older version or even to an alternate db.

In short, I think that keeping with the most recent version of packages is
the way to go to *reduce* maintenence and patch issues (by avoiding the
"code rot" problem) over the long term.


Just my $0.02,

Mike Shell

[Ken Moffat]

Post by Michael Shell
I don't have a strong opinion on it one way or another, but my vote is to
retain the latest version. Oracle is using a GPL license (AGPL) so
redistribution (i.e. a lack of distribution sites) should not be an issue.
The LWN article expressing concern about the AGPL was written in 2013.
Given the way things work with the FSF, many other projects will eventually
be affected by the AGPL issue anyway. (If the FSF wants all source
code/modifications to be publicly available for all GPL/free software that
has been modified and that provides, or is linked to that which provides,
public web services, then it will evolve the GPL as needed to achieve that
goal world wide.)

Using the AGPL for web applications appears to be fine, but using it
for a library - particularly when the copyright owner is perceived
as litigious - gives people who have web applications pause for
thought and it seems to contribute to the reluctance for other linux
distros to use recent versions.

In addition, php does not officially support DB > 5 and openldap say
that the licence of DB 6+ is incompatible with their package (but
using DB 5 for slapd is merely 'deprecated'). Not that I care about
either package per se, the problem is keeping track of possible
breakage if something internal changes.

Post by Michael Shell
Furthermore, recent versions of packages tend to have fewer problems with
recent compilers.

Hmm, not wholly my experience ;) We mostly use released versions
and often changes in a library (icu, poppler are particular
bug-bears of mine) will eventually be fixed upstream by the packages
that use them - but often several months / versions later.

For the last db-5 there is one problem, probably caused by changes
in gcc's default c++ standard - Arch have a patch, we can use a sed.

And in general fedora are good for bleeding-edge fixes - but in
this case they aren't using DB-6 let alone DB-18.

Post by Michael Shell
If there were to arise a significant fork or alternative with regard to the
Berkeley DB, or we could not download it from any site without registering
with Oracle, or if we knew that db-18.1.25 or later broke a significant
number things, then I could see some solid grounds for reverting to an
older version or even to an alternate db.

Many packages were already moving away from Berkeley at the time of
the license change. For us, the problem with using 18.1.25 (and
later 19, 20 if we keep going) is "what changed which might impact
the packages using this ?" The big distros have enough users for
problems to be noticed and fixes prepared. We don't.

As I understand it, downloading from Oracle requires registration,
even for db-5. That's why we're using a secondary site for 18.1.25.

Post by Michael Shell
In short, I think that keeping with the most recent version of packages is
the way to go to *reduce* maintenence and patch issues (by avoiding the
"code rot" problem) over the long term.
Just my $0.02,
Mike Shell

Thanks for the comments. At the moment I'm still planning to drop
it into an experimental build in about a week's time. All being
well (unlikely - I plan to test latest icu and poppler, so some
breakage is likely in other packages) I'll then minimally build the
packages from the systemd book which use it - 'minimally' here means
"fiddle about with options to avoid some of the recommended deps,
and possibly determine that some are now required".

But db-5 is a known quantity in linux, I don't foresee issues with
any package which uses it.

ĸen

[scrat]

On 08/04/2018 06:13 PM, Ken Moffat wrote:

[putolin]

Post by Ken Moffat
Many packages were already moving away from Berkeley at the time of
the license change. For us, the problem with using 18.1.25 (and
later 19, 20 if we keep going) is "what changed which might impact
the packages using this ?" The big distros have enough users for
problems to be noticed and fixes prepared. We don't.
As I understand it, downloading from Oracle requires registration,
even for db-5. That's why we're using a secondary site for 18.1.25.

This works for me using wget with a file of packages to download:
http://download.oracle.com/berkeley-db/db-6.0.20.tar.gz

Never signed on or registered

[Ken Moffat]

Post by scrat
[putolin]

Post by Ken Moffat
As I understand it, downloading from Oracle requires registration,
even for db-5. That's why we're using a secondary site for 18.1.25.

http://download.oracle.com/berkeley-db/db-6.0.20.tar.gz
Never signed on or registered

Thanks. I had tried downloading from firefox and got asked to
register (I stopped at that point).

ĸen