Re: .gitmodules security

Mike Frysinger <[email protected]> Fri, 11 Feb 2022 05:05:45 -0500

Newsgroups	gmane.comp.gnu.libtool.general
Message-ID	<YgY0+eBIqUg4O690@vapier>

On 07 Feb 2022 12:24, Vincent Lefevre wrote:
> On 2022-02-07 05:43:11 -0500, Mike Frysinger wrote:
> > On 07 Feb 2022 09:32, Vincent Lefevre wrote:
> > > what is done on Debian (where the libtool uses the version from the
> > > gnulib package, so that it is interesting to know the behavior with
> > > the current gnulib).
> > 
> > eh ?  packages that leverage gnulib don't get libtool from gnulib.  they
> > get it from libtool.  so i don't know what you're referring to here, and
> > i'm having a hard time guessing what Debian might be doing.
> 
> What I mean is that if I want to test libtool from the git repository,
> I should also try with the latest gnulib from its git repository,
> because this is what I will get in future Debian packages.

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.  if you
wanted to do future checking for the libtool community and send patches
to fix incompatibilities that gnulib introduces, that's reasonable, but
i don't think the flow of always updating the gnulib submodule makes
sense.  especially when the vast majority (if not all) of the modules
that libtool uses from gnulib are maintainer related.  afaict, libtool
isn't pulling in any source code modules.
-mike

signature.asc (application/pgp-signature, 833 B)