On Sat, Aug 04, 2018 at 03:44:26PM -0400, Michael Shell wrote:
>
>
>
> 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.
> 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.
> 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.
> 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
--
Entropy not found, thump keyboard to continue
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
