[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: packages being essential but having stuff in /usr/?!

On 15.07.2010 21:34, Christoph Anton Mitterer wrote:
On Thu, 2010-07-15 at 20:15 +0100, Julien Cristau wrote:
No, and there doesn't need to be.  Now can you stop beating this dead
horse?  It would like to rot in hell unharmed.
Wow,... supposing that you speak for Debian,... this reaction is
really ... "interesting"...

Always thought that Debian would be an open project,... so
- either I'm wrong with my assumptions on the policy and one could
(being so "open") explain the where and why...
- or I'm right,.. than there's somewhere some problem, either in the
policy,.. or the package...

But just saying "go away,... I don't wanna know anything"... and
ignoring that there are e.g. non-dash/bash shells which conform to the
policy as a /bin/sh but still would break here... this is really
Drepper-ism in it's purest form :)

Thank your for that ... uhm... entertainment...

I think it also your fault. ;-)

We understand your concerns. BTW a lot of people tried to solve and
simplify the booting process, but as you see, most of them failed.

It is not a simple task, it is not a theoretical homework
(maybe yes, but it will take a loooot of time to find and
describe the requirements for every supported debian configuration,
nobody success on it, also because new hardwares and setusp).

Allowing new shells is not so simple as you may things,
it is not only about shell syntax, build-in programs, etc.,
but all libraries and support program needed by the shell]

[Note: bash already fails on few setups, because of NIS+ IIRC]

Also the booting system is a changing area
We moved from sysv style to inserv, and maybe will go to upstart
or systemd. So a new policy requirements should be enough generic
also for transitions.

IMHO requiring that at call of /bin/init (the first program
called in the new root filesystem at boot) that the "essential
debian system" is ready it is IMHO very impractical for
many setups.

Moving things to initramd (or to inittab) don't solve the problem
you only more one/two layers earlier.

And talking about stages is also impractical with the
new inserv/upstart/systemd concept.


Reply to: