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 ebl...@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
