Hi!

On Fri, 2019-03-15 at 00:37:33 +0100, Santiago Vila wrote:
> Maybe, but this is neither a new miscellaneous file nor a new
> bootstrapping action. This is yet another bootstrapping tool
> forgetting the lessons learned from the other bootstrapping tools.

My impression though is that the general consensus is that the
lessons learned from the traditional bootstrapping tools, is that
they are doing it wrong. :)

> Helmut Grohne wrote:
> > How is a bootstrap tool supposed to know
> > that it must configure base-passwd before base-files?
> 
> In a theoretical level, because it's their job to know such things.

As it's been mentioned elsewhere, this is not a property that is
necessary. In the same way that bootstrapping an architecture should
not require manually tracking the order of the build-dependencies
and cycle breakings (which was the case before), etc, even if that
might still be partially the case now, while we have not fully added
build profiles and cross-building support everywhere necessary.

> 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.

> 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.

> But lack of such a common framework is not an excuse to ditch the
> definition of essential and start doing things "just in case"
> some new bootstrapping tool forgets again that there must
> be a valid /etc/passwd before configuring anything else.

You seem to keep using the definition of essential to justify this,
but as I've mentioned elsehwere, the definition of essential does not
cover what happends before the system has been bootstrapped. If we'd
consider that policy already covers it, that would mean most essential
packages are RC buggy.

(And as I've mention on another reply, dpkg f.ex. is already falling
back to numeric UIDs "just in case". :)

> 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?

Thanks,
Guillem

Reply via email to