Re: essential and transitivly-essential
* Colin Watson <cjwatson@debian.org> [120201 12:32]:
> 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.
Only direct dependencies. If some package does not Depend on an
essential package (as it is supposed to not do) the the package's
postinst can be run before the dependencies of that other essential
package's postinst is run. Any functionality of the essential
package provided by it's dependency must thus already be available
AFAIUI.
> > - 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'.
Does debootstrap's first stage ever ends in an actually bootable
system? (after all, at least boot loaders are definitely missing,
initrds are missing, ...).
The only way I know this running is with chrooting in the
prepared directory from some other Linux system or a rescue
system. And in that case most of this should just work the
same (some packaged would be unpacked the first time and not
the second, but...).
The only thing I see with a quick glance is mounting
/proc. But that could equally well done from outside.
> 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
Additionally such bugs are hard to find as having only debootstrap
and cdebootstrap may do stuff in the same order most of the time thus
hiding it.
> 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?
The case I'm stumbling over this regulary is small buildd chroots.
With some older hardware maintaining chroots can be quite daunting.
Reducing the set of packages needed in one can easily be the
difference between a viable and a unusable solution.
(I've also experimented with locally testing builds on other
architectures by some minimal qemu tricks and usually this bloat
the the induced brittleness of bootstrap phase stopped me).
> 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;
That's an valid point. But that is only about the naming.
> 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).
That together with some check to reject packages in that set depending
on packages not yet in that check would give a good way to review
such changes, though, and avoid anything happening in that regard
by mistake.
> 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".
My point also is that Essential currently means two things:
"Needed so that other packages can be installed" and
"should not be easily removed by the user".
Thus I'd like to see Essential split in a part to be in every
chroot and taking special treatment and a set of packages not
to be removed easily but still possible to remove where not
needed (like mount, initscripts, ...).
> > - 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",
My suggestion contains the proposal to reduce that to only a subset
of that.
Bernhard R. Link
Reply to: