Bug#924401: base-files fails postinst when base-passwd is unpacked
> > In a practical level, because you already see what happens when
> > you configure any package which uses users defined in /etc/passwd
> > without a minimal /etc/passwd in place. Again in a practical level,
> > once we know it, we can't pretend that we don't know it.
>
> That's what the traditional bootstrapping tools have been doing, and
> it's all kinds of wrong. For example whether a system even uses an
> /etc/passwd is an implementation detail of that system. Some don't
> even have one. If we added support for such a port, then in addition
> to patching the relevant code that directly deals with this, we'd
> need to also adapt all the bootstrappers to cope with this. Instead
> of them just automatically just working out of the box, w/o needing
> to hardcode package names, internal implementation details, etc.
Following such reasoning, the uids defined in /etc/passwd are also an
implementation detail that base-files should not need to know. Moving
such information from base-passwd to base-files and hardcoding it
seems a step in the wrong direction for exactly the same reasons.
> > You want to create a common framework to reuse such knowledge and
> > share it between different bootstrapping tools? Fine, maybe then new
> > bootstrapping tools finally realize that there must be a valid
> > /etc/passwd before configuring anything else.
>
> That knowledge is already in each relevant package, the passwd stuff
> in the base-passwd package (in Debian) or possibly elsewhere in other
> systems.
So, base-files does not need to know the uids defined in /etc/passwd
because such information is already in the base-passwd package.
> > Please reassign to whatever bootstrapping tool is not doing its job
> > properly. Sorry, but this is starting to annoy me.
>
> I'm sorry to hear, but TBH, I'm a bit puzzled about your replies. That
> might be due to the apparent conflation of trying to look for a better
> solution to the problem presented, and how to incrementally transition
> to such a bettter place smoothly already right now?
>
> It's not clear to me whether you oppose the discussion about such
> proposals because you consider the current bootstrapping method the
> ideal solution, or whether you oppose any progressive move towards
> those, as in an all or nothing scenario?
I'm not opposed to discussing new proposals. The current bootstrap
methods may not be ideal, but they are ok to me as far as they do
their job.
My annoyance, as you have rightly pointed out, comes from conflating
the discussion of new proposals with the present problem in the
present bootstrapping tool.
New proposals to bootstrap Debian are welcome here. Trying to fix a
bug in a bootstrapping tool by changing base-files, which is not to
blame for such bug, is annoying me. (So, Helmut, please file a bug
in the bootstrapping tool which does not work for you, and do not
try to fix it here).
I do not exclude the possibility of incremental changes, but the ones
I've heard so far seem steps in the wrong direction to me.
One idea that was floating around was to make dependencies on
essential packages from essential packages explicit instead of
implicit. Does anyone have any idea about how such thing would work?
Would that improve things? Would dpkg and current bootstrapping tools
allow internal simplification or "factoring" if we did that?
Would they still work at all?
Thanks.
Reply to: