Re: packages being essential but having stuff in /usr/?!
On Fri, 16 Jul 2010, Christoph Anton Mitterer wrote:
> But I think:
> 1) the policy description of essential should be clarified then, as now
Essential means that the *package* essential functionality (not all of its
contents or functionality) has to be available at all times in the lifetime
of the *package*, which is related to it being upgraded/replaced. It
certainly has nothing to do with the lifetime of the *SYSTEM* runtime.
What the essential functionality of a package is varies with the package,
and it is far more related to the needs of dpkg and a subset of the
maintainer scripts, than anything else.
The people who have to deal with Essential packages are *required* to know
in depth everything Essential really means and why. Debian Policy doesn't
(and has never) gone into that level of detail, AFAIK.
> it really reads "be available and usable on the system at all times".
> I guess we should at least exclude initramfs from that,... an perhaps
> also all or parts of the boot process.
Unless you propose a *conservative* patch to the policy text through the
proper channels, nobody will care. It is an old horse, really.
It is not like you have any room to wiggle in these strictly technical
matters, so there is little need for policy to steer things. If you don't
get it exactly right, things break *badly*... and there is usually very few
ways to get it exactly right.
> Why do I think this is important? Well,... one thing the policy implies
> on essential packages is, that you don't have to depend on them (in
> terms of package dependencies).... I guess its logical to conclude that
> one also doesn't have to check for the core stuff like cp/cat/rm... this
> would really clutter many scripts.
If you have ANYTHING hooked to udev or the initscripts/upstart subsystems,
and not depending on $remote_fs, you are *REQUIRED* to know what the hell
you're doing. It is that simple.
initramfs is probably even more restrictive :)
> But right now one may think that _all_ coreutils packages are guaranteed
> to be always there.
Then, that one is not only not ready yet to deal with early userspace or
udev hooks, which would be the only situation where it would matter.
> 2) Personally, I'd prefer to put some of the current /usr/bin utilities
> from coreutils to /bin, especially [, test, printf ... but actually some
> more...
> I guess this makes /bin not much larger, but would be a nice benefit.
You will have to state strong and specific requirements for every utility
you want to move to /bin or to /sbin. It won't be done "just in case". And
it obviously means anything that utility uses (e.g. any libraries, and the
dependencies of these libraries, etc) must also be moved to / (/lib, /sbin,
/bin, /etc...)
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: