Thanks for bringing this up. This point is actually relevant for a
change I was considering this week.
As you pointed out, `libtool' "really" doesn't need to be synced with
the most up to date `gnulib', since really these are all "developer
dependencies". The only parts of this which are a bit of gray area are
things like `option-parser' and `extract-trace', but I don't see any
compelling reason that these need to be synced with the most recent
updates to those modules.
Using the most up to date modules wouldn't normally be harmful; except
that they do add a significant amount of complexity to the `bootstrap'
phase for `libtool', and really throw a wrench in the Hydra CI system (
this isn't the fault of `gnulib' really, Hydra just doesn't support
`git' submodules in a robust manner ).
I was considering consuming both the `bootstrap' and our other `gnulib'
modules into the `libtool' repository, and adding a script which would
explicitly perform updates ( perhaps annually ). Aside simplifying the
`bootstrap' phase and alleviating Hydra headaches, it would also
eliminate the security concern you've raised.
If anyone has compelling counter-examples against such a change please
let me know. I'd definitely enjoy running Hydra builds again without the
headache of manually performing the `gnulib' submodule sync behaviors -
since that is what causes existing failures.
On 2/11/22 4:35 AM, Vincent Lefevre wrote:
On 2022-02-11 05:05:45 -0500, Mike Frysinger wrote:
i'm not sure that's accurate. if you look at the history of the gnulib
submodule, it's updated maybe once a year. gnulib doesn't need to be
synced to its latest commit all the time to work. i think any automated
distro testing should be focusing on what the git repo is using.
[...]
It seems that in 2016, the Debian libtool maintainer chose to use the
gnulib code from the Debian package instead of the one distributed
with libtool. In the Debian changelog:
* Build-Depend on gnulib and tell bootstrap where to found it.
In general, when 3rd-party code is used by a project, Debian prefers
to use the version it provides via its own packages rather than the
version used by upstream (even though this may yield API and ABI
compatibility issues), apparently because it is easier to apply
security fixes (what upstream doesn't always do, in particular
because active Debian releases may still have versions that upstream
no longer supports). But I don't know whether this is the reason for
libtool.