Re: backupfile and backup-rename are introducing the same object to make

[GalaxyMaster <galaxy@openwall.com.au>]

Bruno,

On Thu, Jan 26, 2023 at 11:19:39AM +0100, Bruno Haible wrote:
> > I clearly understand that my use case is not something supported or endorsed by
> > the GNU Lib project and am not trying to change that, but it is another avenue
> > to test stuff, which may be valueable to the project.
> 
> I have nothing against experiments. But you have to take into account that
> GNU gnulib (that's the actual name, not "GNU Lib")

Thanks, noted.

> does not attempt to have backwards compatibility constraints as usual for
> shared libraries. This is written in the documentation

Yes, I am aware of that and it is not a big issue for my project.  I am
currently torn between two approaches:

 1. closely monitor changes between sync points and follow the libtool
    recommended approach on library versioning (when revision is incrementally
    changed on any change, age is incremented on additions, and current is
    incremented on interface changes).  Despite gnulib's changelog is good in
    this regard, I am still thinking of finding an automated way to monitor this;

 2. do a sync quarterly aligned with the release of a new version, which
    includes rebuilding everything.  This is more aligned with gnulib's
    philosophy in terms that the whole distribution I am creating can be
    considered as a package that uses GNU gnulib and everything beneath like
    coreutils or bison, for example, are just subcomponents.

My preference is automated version of the first approach.  And, if I am
successful and can prove it to be viable, I will contribute back in a form of a
separate project that is focusing on making GNU gnulib buildable as a
standalone library.  Looking around and seeing Gentoo packaging a system-wide
gnulib (https://packages.gentoo.org/packages/dev-libs/gnulib) and using it in
their package builds, NixOS doing something similar
(https://github.com/NixOS/nixpkgs/blob/nixos-unstable/pkgs/development/tools/gnulib/default.nix),
and many others -- I think it may be valuable, if not it would be still
valuable to me :).

One thing that I really appreciate (and am not trying to conquer) is that GNU
gnulib as a project cares about all the different platforms and my effort is
focused purely around Linux-based ecosystem, hence I do not see a possibility
to merge my work back into gnulib (testing across all architectures supported
by GNU gnulib is a huge task).  This does not preclude me from contributing
in other ways, though :)

> You need to think about how you will handle these changes.

Thanks for kind words, I do consider these and thought quite a bit on the pros
and cons.  In the end, I found that it would be more efficient to spend time on
one of the two approaches described above rather then try to hunt down each
individual package that introduces local changes to GNU gnulib they are
bundling.  E.g. make (https://git.savannah.gnu.org/cgit/make.git/tree/gl) and
coreutils (https://github.com/coreutils/coreutils/tree/master/gl/modules) are
extending the GNU gnulib, some packages (I cannot easily recall the names) are
introducing non-GNU modules or patched versions of gnulib's modules, etc.

From the system engineering point of view, it is more viable to perform a
"surgery" on a package once, when it is entering the build queue and strip it
off its ties to the bundled, perhaps hacked version of gnulib and convince
package's build system to use a centralised, verified copy.  At least, this is
my theory, I am at the begining of the path with less than 20 packages using the
shared version of GNU gnulib, but among these are systemd and coreutils, so if
I do not tread carefully it will result in a borked system :).

-- 
(GM)