reopen 627068 thanks Until the documentation is clarified, keep the bug open. It's now merged with another one.
On Tue, 17 May 2011 16:29:32 +0200 Daniel Baumann <[email protected]> wrote: > On 05/17/2011 04:09 PM, Neil Williams wrote: > > Unjustified severity. Lowering. > > well, multistrap is a tool to bootstrap. if you can't bootstrap, that's > a major fail, isn't it? (regardless whichever you prefere, serious or grave) Multistrap does bootstrap, it is certain packages which need differing solutions and those do not cause issues with the majority of uses of multistrap. The principle role is the generation of root filesystems, typically embedded and typically for non-trivial systems which require custom setups for particular boards. Depends on your definition of non-trivial. In most cases, it means a non-standard configuration and device table along with packages from internal or non-Debian repositories. > > There is no Policy requirement here, it is simply what packages have > > come to expect but it is not possible to handle preinst scripts in this > > way in multistrap because multistrap is architecture-neutral (not just > > architecture-independent) and must deal with foreign builds in the > > same manner as native, subject to a small convenience wrapper for > > running 'dpkg --configure -a'. > > i don't understand, why *exactely* do native and foreign bootstrapping > runs have to be handled identical? For the multiple repository dependency resolution and because the principle objective with multistrap is for root filesystem generation which is typically a foreign process. > >> base-passwd is an essential package. > > > > Essential is not the predicate here, it is Priority: required which is > > a much wider set. > > daniel@daniel-desktop:~$ apt-cache show base-passwd | grep Essential > Essential: yes > daniel@daniel-desktop:~$ debootstrap does not use this field, it bases things on Priority: required and Emdebian has no Essential field at all. You're looking at the wrong field - check the debootstrap scripts and it's Priority: required. Essential has nothing to do with unpacking order or the preinst scripts - it is simply a shorthand for dependencies. Everything related to which packages debootstrap unpacks first is based on Priority and apt uses it to hint to users that what they have asked is something which could easily break the system. > > There is no way to identify the ORDER in which > > preinst scripts in Priority: required should be run other than > > explicitly slaving to the debootstrap method of only unpacking *and > > configuring* Priority:required before even trying to download the rest > > of the packages. This fundamentally breaks the multi-repository model > > of multistrap and can ONLY work natively which is why debootstrap has > > such problems when using --foreign. This is the fundamental reason why > > debootstrap cannot support multiple repositories with --foreign - it > > must rely on a fully configured Priority: required set before the rest > > of the dependencies can be calculated. > > sorry, i don't understand, what is the problem of fetching the indices, > extracting all essential packages, download and install them and then do > the rest? Extracting does not run the preinst because it cannot on a foreign architecture, so you gain nothing because base-passwd relies on the postinst. So the typical case is to provide what the base-passwd postinst would create as a static file. multistrap does not fetch the indices and extract, that's the debootstrap model and it fails utterly for multiple repositories - multistrap uses apt to get the dependency chain and then unpacks the archives. This is done explicitly to avoid running the preinst scripts. dpkg --unpack is fundamentally different to dpkg -X - multistrap explicitly uses -X because --unpack relies on running every preinst. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
pgpdGpVlJzH4P.pgp
Description: PGP signature
