Re: essential and transitivly-essential
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 [cjwatson@debian.org]
Reply to: