[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bootstrap: allow more than one submodule
From: |
Eric Blake |
Subject: |
Re: bootstrap: allow more than one submodule |
Date: |
Tue, 16 Mar 2010 04:23:02 -0600 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.8) Gecko/20100301 Fedora/3.0.3-1.fc12 Lightning/1.0b1 Thunderbird/3.0.3 |
On 03/16/2010 04:16 AM, Bruno Haible wrote:
> Hi Eric,
>
>> What's the use case for updating some, but not all, submodules?
>
> Imagine a package that has submodules 'gnulib', 'libxml', 'libcroco'
> (like GNU gettext might have). It would be perfectly normal for the
> developer to stay with the last known good libxml and libcroco but
> try the newest gnulib.
>
> Or a package that has submodules 'readline' and 'gnulib' (GNU bash may
> come to mind). It would be reasonable for this developer to update
> readline to the newest development version but stay at a stable gnulib.
Indeed, bison already uses multiple submodules (gnulib and autoconf),
and has done for more than a year. It may be worth getting Joel's
opinions here, as the maintainer of the only GNU package that I am aware
of that currently tracks multiple submodules. But my experience from
browsing the bison lists is that ./bootstrap is for getting the package
into the shape that upstream left it, then git commands are for getting
one (or both) submodules updated to a newer state, because updating a
submodule often implies updating other code as part of the same commit
in order to work cleanly with upstream changes. Since bootstrap cannot
make those other changes, and since committing a gnulib update in
isolation might result in a commit that fails during bisection testing,
it seems better to not make bootstrap the driving force that updates
submodule state.
--
Eric Blake address@hidden +1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature