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

[Bruno Haible <bruno@clisp.org>]

GalaxyMaster wrote:
>     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;

Unfortunately this typically involves developer knowledge about the package.

There is some helper script gnulib/build-aux/libtool-next-version that
helps avoiding mistakes when assigning the LTV triple of a shared library.
It looks at the "nm" output of the library in the current and in the next
version. But it still requires judgement: When a function's implementation
changed in such a way that its results will change, are these modified
results a "major" or a "minor" change?

And when you say "ok I'll try to err on the safe side, if in doubt I'll
bump the major version", then it's an effort for the distro because they
have to rebuild some more packages. Cf.
  https://lists.gnu.org/archive/html/bug-libunistring/2022-12/msg00001.html

>  2. do a sync quarterly aligned with the release of a new version, which
>     includes rebuilding everything.

Note that it's quite frequent that changes to gnulib are being made in the
prerelease phase of some other package. For example, there were some gnulib
changes yesterday for the GNU poke 3.0 release that happened today. If you
have a quarterly schedule regarding gnulib, it means that you will have to
wait until 2023-04-01 until you can package poke 3.0. (You'll decide whether
that is acceptable for your distro. I'm just giving you a heads-up.)

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

Maybe we can get some advancement if you describe why, in the first place,
you want to do this package "surgery" in the first place. I don't want to
judge what you are doing; I wish to listen and understand if on the Gnulib
side we can do something a little bit differently, so that it would help
regarding your points.

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

You say "centralised". Why is it a problem if, e.g. GNU make uses some set
of (possibly modified) gnulib modules, and GNU coreutils another set, and
they use different versions? Binary code size / efficiency of using the RAM?

You say "verified". Why is it a problem if some GNU package has decided to
modify a gnulib module? This is supported, see
https://www.gnu.org/software/gnulib/manual/html_node/Extending-Gnulib.html
Are there reasons not to trust the modifications done e.g. by the GNU make
maintainer, when you do trust him for the other parts of the GNU make source
code?

Bruno