severity 627068 normal thanks On Tue, 17 May 2011 15:24:17 +0200 Daniel Baumann <daniel.baum...@progress-technologies.net> wrote:
> Package: multistrap > Version: 2.1.13 > Severity: serious Unjustified severity. Lowering. 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'. > base-passwd is an essential package. Essential is not the predicate here, it is Priority: required which is a much wider set. 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. > on a regular system, any package > that gets installed after base-passwd can expect /etc/passwd to be > existing and can therefore do stuff with users (e.g. calling a chown in > postinst) without having a depends on base-passwd. Doesn't affect multistrap because the primary purpose is foreign, so the preinst scripts cannot be run anyway. > during a multistrap run, all preinst scripts of the to be installed > packages are run first, It is not possible to identify a reliable alternative sequence. It may be manageable to create config scripts which try to isolate the Essential: yes packages but these packages do not exist in Emdebian, so that would be of little benefit and the problem isn't Essential in the first place, it's Priority: required. > then all postinst scripts. if a package is doing > stuff with users (e.g. calling a chown in postinst) and the postinst of > base-passwd is not run before that, /etc/passwd is missing, the postinst > fails and multistrap could not bootstrap. Then those packages should be listed in the reinstall section so that the configuration can be tried again later. Alternatively, provide a static configuration containing what is required, as per typical embedded root filesystem creation. > means, it's not possible to multistrap any system that has any package > that is doing any user modification whatsoever. Not true. It is possible if the configuration required is provided before the first preinst scripts are run. > since these are quite a > few packages (legitimately!) in the archive doing that, multistrap is > essentially broken and can unfortunately not be used for any non-trivial > system. Not true. Multistrap can be used for a wide range of package selections BUT the configuration of each package set does differ and certain packages need configurations put in place ahead of the preinst. > the solution is to process first all preinst scripts of the essential > packages, then all postinst scripts of the essential packages, and then > the same for all non-essential packages. Not possible. Multistrap is architecture-neutral and needs to remain that way. See #591518 I was tempted to close this bug immediately because there is nothing multistrap can do here which is replicable on a foreign architecture run and foreign is the primary use case for multistrap. Equally, Essential is *not* reliable - debootstrap doesn't actually use it - it is usually Priority: required which actually happens as a pre-setup stage before more complex packages are even unpacked. Multistrap cannot operate in such a manner because of the preinst on foreign architecture problem. There is currently no general fix for this situation, it needs to be handled on a case-by-case basis in the various config script and setup script or hook support. In the vast majority of cases, multistrap root filesystems do not actually allow the creation of users when packages are unpacked, the user list is designed in from the start. If your package list includes packages which require specific users, the typical response would be to ensure that those users already exist by providing the relevant files in the root filesystem in advance. This avoids the need to run anything as a foreign architecture. The same goes for other hidden assumptions in the way that packages assume that Priority: required is 100% "install ok installed" before hand. This behaviour is necessary for multistrap to provide multiple repository support for foreign architectures. If it inconveniences native runs then that is unfortunate but the same methods which are routinely used to handle these situations with foreign architectures will work just as well with native. It is not something that multistrap itself can do anything about. I will leave this bug open for a little while but unless there is a better idea, I will have to close it. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
pgplG3SvP1oro.pgp
Description: PGP signature
