* Steve Langasek <vorlon@debian.org> [110404 19:22]:
> If login worked consistently in the face of the configured shell going
> missing (automatically falling back to /bin/sh for root), then I think it
> would be worthwhile to do the work necessary to remove bash from the
> essential set. But until then, the primary purpose of Essential, to me, is
> the "minimal set guaranteed to be usable" aspect, not the "you don't have to
> depend on it" aspect.

I think it might be nice if those two aspects could be isolated somehow.
This could also reduce the size of some build chroots and the set of packages
any boot-strap code has to handle specially[1]. With all the essential
stuff only needed for a full system to boot, those are larger than they
needed to be.

I think

e2fsprogs
login
mount
sysvinit
sysvinit-utils
util-linux

and their dependencies (passwd, initscripts, the whole pam stack)
are mostly not needed in that set[2].
(Util-linux might have one or two programs one might want to move
to another package then, and something for update-rc.d needs to be
done).

How about giving the old meaning of Essential to packages being
Essential: yes and Priority: required and allowing a new state
Essential: yes and Priority: important that means a package manager
has to make sure its functionality is kept[3] but everything not
having a Dependency is still supposed to work (do build chroots,
embedded stuff or other things can do without them).

Bernhard R. Link

[1] bootstrap code essentiall needs to unpack those and all their
dependencies manually and then call dpkg to do that again...

[2] At least I often build some of my packages in chroots not having
any of those.

[3] Though in my eyes "not removed" might suffice. Being able to login
always but having no guarantee a sshd is still running and working or
that it is still bootable gives not much in my eyes.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110405141822.GA6480@pcpool00.mathematik.uni-freiburg.de">http://lists.debian.org/20110405141822.GA6480@pcpool00.mathematik.uni-freiburg.de

On Tue, Apr 05, 2011 at 04:18:22PM +0200, Bernhard R. Link wrote:
> * Steve Langasek <vorlon@debian.org> [110404 19:22]:
> > If login worked consistently in the face of the configured shell going
> > missing (automatically falling back to /bin/sh for root), then I think it
> > would be worthwhile to do the work necessary to remove bash from the
> > essential set. But until then, the primary purpose of Essential, to me, is
> > the "minimal set guaranteed to be usable" aspect, not the "you don't have to
> > depend on it" aspect.

> I think it might be nice if those two aspects could be isolated somehow.
> This could also reduce the size of some build chroots and the set of packages
> any boot-strap code has to handle specially[1]. With all the essential
> stuff only needed for a full system to boot, those are larger than they
> needed to be.

> I think

> e2fsprogs
> login
> mount
> sysvinit
> sysvinit-utils
> util-linux

> and their dependencies (passwd, initscripts, the whole pam stack)
> are mostly not needed in that set[2].
> (Util-linux might have one or two programs one might want to move
> to another package then, and something for update-rc.d needs to be
> done).

I think this is a false optimization. How does reducing the set of packages
in a buildd chroot help anything? A typical package has build-dependencies
many times the size of the Essential set.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org

* Steve Langasek <vorlon@debian.org> [110405 20:29]:
> > I think it might be nice if those two aspects could be isolated somehow.
> > This could also reduce the size of some build chroots and the set of packages
> > any boot-strap code has to handle specially[1]. With all the essential
> > stuff only needed for a full system to boot, those are larger than they
> > needed to be.
> >[...]
> > and their dependencies (passwd, initscripts, the whole pam stack)
> > are mostly not needed in that set[2].
> > (Util-linux might have one or two programs one might want to move
> > to another package then, and something for update-rc.d needs to be
> > done).
>
> I think this is a false optimization. How does reducing the set of packages
> in a buildd chroot help anything? A typical package has build-dependencies
> many times the size of the Essential set.

It might not be so big a saving for build chroots sizes (though I guess
it will in the mayority of cases be more than 5%). For package install
tests I guess it would be much more significant.

More importantly is the boot-strap code. Currently everything in the
required set gets a special handling, must be unpackaged twice and is
supposed to work in quite a special situation (all files existing in the
file system but no pre/postinst yet run, ...).

Such a step would almost reduce the packages to a half (something like 61 to 33).

Bernhard R. Link


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110406072426.GA31381@pcpool00.mathematik.uni-freiburg.de">http://lists.debian.org/20110406072426.GA31381@pcpool00.mathematik.uni-freiburg.de