[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: 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

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]