Re: Updating a package's gnulib files in CVS

[Simon Josefsson]

address@hidden (Karl Berry) writes:

>     The three possibilities are listed in
>     http://www.gnu.org/software/gettext/manual/html_node/Files-under-CVS.html
>
> There's another possibility, which apparently both you and I follow in
> different ways: commit some (but not all) autogenerated files.
> It doesn't have to be an all-or-nothing decision.
> For my purposes, it's useful not to commit gnulib files; for your
> purposes, I can see how the opposite is true.

That is what I do in my projects too: I commit gnulib files, but not
other "generated" files.  The problem I have with switching to any other
mode is reproducibility.  When checking out an old version of my
software, how can I be sure to get the appropriate gnulib files?  How do
others that use the bootstrap tool solve this problem?

The way I see this working could be: in configure.ac (or possibly
gnulib-cache.m4) I put a

gl_REVISION([abc6ba7cb8ac9acb9acd..])

which would be the git revision of gnulib to check out.  Then some tool
-- possibly build-aux/bootstrap? -- could check out that version.  Then
I always get the same gnulib files.

To upgrade to a newer version of gnulib, which would be a manual
operation, I would bump the sha1 hash in configure.ac, import the gnulib
files, and manually fix all problems that may lead to, and then commit
that in my project.  Possibly the bootstrap tool could have a parameter,
say bootstrap --upgrade, to modify the gl_REVISION stuff in configure.ac
for me.

Is this idea useful?  Thoughts?

/Simon