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