On Wed, Feb 01, 2012 at 11:03:44AM +0100, Bernhard R. Link wrote: > It's also a pity that it is not that easy to see which packages are in > this set. Given that transitively-essential means: > > - the package must be unpackaged manually > - it must work without any preinst or postinst script being run > (at least good enough for dpkg and all the other essential and > transitivily essential's packages preinst and postinst).
Only their preinsts; dependencies will still be configured in time for postinsts, as long as they aren't circular. > - Add a new priority "essential" for the "must always be available" > (so this is what in a bootstrap is unpackaged manually). > Require that Priority essential packages only depend on Priority > essential, so this is the new transitively-essential set. > - Reduce "Essential: yes" with "Priority: required" to mean only > that cannot be removed easily. So things like mount or initscripts > must not be unpacked twice and available in every buildd chroot. I'm afraid weakening the constraints on "Priority: required" packages would break debootstrap's --foreign/--second-stage system. For that to work (at least without emulation), 'debootstrap --foreign' needs to be able to unpack enough packages that you can actually boot the target system and run '/debootstrap/debootstrap --second-stage'. In practice this means "Priority: required", and so, in order to support this, packages like mount and initscripts need to be able to cope with the model where they're unpacked before any packages are configured anyway. Given that, it doesn't really hurt us to do single-architecture bootstraps that way as well. I appreciate that this might be a harder sell if it didn't already work, but given that it does, we'd need a pretty strong reason to break it. In any case, I don't know that this would justify the time spent on it. It's true that it would eliminate the occasional bug, but in practice things that are "Priority: required" do tend to act pretty carefully; I think I can recall one case ever where I encountered a package that failed to cope with debootstrap's unpack régime, and IIRC it was something that was being pulled in via --include rather than actually something in required. It's not that such things don't merit review - they do, and I agree with Steve that some discussion is worthwhile - but I don't think there's a lot to be gained by redefining things so that we can reduce the current set, given that it wouldn't actually reduce the size of debootstrap's output on user systems. Do you have a specific case where this would have made a difference? I also think that the jargon term "essential" is often misunderstood as it is, and changing the system to apply it to two things rather than one would confuse the situation further; not to mention that Priority has to be manually maintained by ftpmaster, while the transitively-essential set is subject to change (debootstrap actually only takes "Priority: required" as a starting point, even though it's usually accurate). If we were going to do something like this for single-architecture bootstraps, I'd prefer to do it by changing debootstrap to resolve the transitively-essential set by itself; that is, take all "Essential: yes" packages and expand their dependencies, and treat that set the way we currently treat "Priority: required". Then required and important would still have their distinct semantics in policy, but debootstrap could install them in one go in what's currently its second stage (or just required + apt with --variant=minbase, or whatever, or something even smaller with --variant=buildd, or whatever). You could experiment with that kind of thing without having to change the archive structure at all. However, you'd still have to remember to take the foreign-bootstrap case into account. Finally, I think it would be a good idea to document the special restrictions on "Priority: required" packages in policy. I don't think it currently specifies these accurately, so they're largely encoded in the heads of the small number of people who've had to deal with this. > - Reduce the set of "does not need depended on" to "Essential: yes" > and "Priority: essential". "Does not need to be depended on" is already only "Essential: yes", even if buildds don't always catch every violation of this. procps is the usual case I see people forgetting about. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120201113144.gb6...@riva.dynamic.greenend.org.uk