Hi all, I'm being heavily bitten by this one as well and I'm mildly shocked to see it crop up this late in the release cycle. I'm not going to hide that I believe this ought to be reassigned to base-files. I'll try to elaborate below. Santiago Vila wrote: [...] > In this particular case, I believe the reason for the failure (that > didn't happen before) is some change in base-passwd, not something > that base-files does differently now. > I tend to disagree: base-passwd hasn't been touched since 2014-09-04, whereas debootstrap only started to fail last week, when base-files 7.7 was uploaded. It's this change I believe: http://sources.debian.net/src/base-files/7.7/debian/postinst.in/?hl=132,133,134#L132 Causing chown: invalid user: 'root:root' Admittedly, though, this just exposes a problem that had been lingering for a while as the calls to chown using root:root could have been invoked from several bits of the postinst script. > In principle, every essential package may depend on any other, and the > set of real dependencies may change over time, so it's natural that > debootstrap needs minor adjustments from time to time. So would you expect some sort of versioned dependencies in debootstrap? As the upload of base-files 7.7 showed, it is changes in packages that suddenly require new hacks. And a key problem is that tools like debootstrap ought to work from within, e.g., stable release to bootstrap future releases like testing or unstable. Suggesting that a bootstrapping tool is changed due to updates in another package is going to cause a major dependency loop as at least testing efforts such as those of jenkins.d.n will be broken. In fact it would be easier to codify this in dpkg than in debootstrap, I believe, as dpkg would live in the same suite as the package to be installed. But this sounds like very bad design indeed. > > > You will find a more complete explanation of this in the logs for > > > Bug#760568 where I'm asked no less than to depend on base-passwd, > > > which is essential! IMHO, this is definitely not the way to go. > > Using the "essential!" hammer doesn't sound like a great argument when your package is essential. > > It's past time to be untangling the Essential hairball. Correct dependency > > metadata is much more scalable than hacks in debootstrap. > > I agree that you may have a point here. In fact, in the aforementioned > bug #760568 against cdebootstrap, which is very similar to this one, > I suggested the idea that if the knowledge about right package ordering > among essential packages were codified and written somewhere, other > similar tools could use the same information without having to > reinvent the wheel. > > I see now that the control file could be such common place to have > that information, but I would like to see a little bit of *design* > before doing anything which is not in policy yet. > > For example, we could use: > > * The same Depends field we are using for normal dependencies. > > * A new field for this particular purpose which dpkg and friends > ignore under normal circumstances, and an environment variable which > debootstrap may set to tell dpkg and friends that they should actually > honor them instead of ignoring them. > > * An extension of the Depends field, much like <!stage1> is used in > Build-Depends for build profiles. > > So yes, we could consider to codify this metadata (the fact that > base-files postinst uses "chown" and expect the root user to exist, > for example) in *some* way... > > > Stop being part of the problem, and add the dependency already.. > > ... but please let us think about it first. Starting to add "Depends" > field here and there in a random fashion "just because it makes > debootstrap not to fail anymore" is not something I will be happy > with. > I do fully agree that care must be taken, as dependency loops would obviously be a major problem. > The Depends field is implicit among the set of essential packages. I'm not too sure about the "among" bit here? No doubt that this is implicit for any non-essential package, but "among" them I'm not sure whether any rules apply right now? > If a tool like apt-get or dpkg really behaves in a different way when > I add a Depends field which was already implicit, I think that there > is something fundamentally wrong here. > Does dpkg really add the "essential" information into its dependency information? Wouldn't this rather be seen as "ah, essential, so it must be there?" At least briefly looking at dpkg's source code I cannot seem to see dpkg considering this implicit dependency at all (unless attempting to remove an essential package). > So, to summarize: I'm not opposed to modify policy when it says that > we don't need to include dependencies on essential packages, but if we > decide to go that route, please let us do it according to some *plan*, > not in a random fashion, because otherwise, IMHO, *that* would be the > real hack. > I do appreciate being careful, but then bug fixes for a bug of normal severity (#763405) shouldn't be causing RC bugs either. Best, Michael
Attachment:
pgpgTH22h3Myq.pgp
Description: PGP signature