Hi Santiago, On Wed, May 18, 2016 at 12:05:28PM +0200, Santiago Vila wrote: > A few comments about this:
Thanks for your quick reply! > * The idea is certainly interesting, but I would try to use a better > rationale for this project. In the current rationale I see in the wiki > page you quoted: > > https://wiki.debian.org/Teams/Dpkg/Spec/InstallBootstrap > > it happens that 3 out of 3 examples are bugs that were filed against > base-files but were really bugs in other packages. That page indeed does not accurately describe my motivation for working on this. Guillem Jover proposed merging the DPKG_ROOT approach into that page. Maybe it is not the best place indeed. I am mainly motivated in bootstrapping architectures, so in my use case chroot(2) really cannot be used at all (because qemu is not available/working for all relevant architectures). Creating foreign architecture chroots currently is a real pain and that's what I want to fix. > * You say that this is an experimental feature. Could not we assume > for a start that the host system is a Debian system? I refer, > naturally, to the tricks in the patch regarding /etc/passwd and chown. I am happy to assume that, but Guillem Jover isn't. We do expect to be able to run debootstrap on non-Debian systems and if this approach is to be used for debootstrap eventually, then it will have to work in such a setting. For that reason, I went ahead and optimised for portability. For my use case (as above), the stronger assumption holds. I had hoped that there would be consensus on the weaker assumption at least, but that doesn't appear to be the case. How about another approach to chown? Since user ids are never changed to base-passwd and we know that base-passwd is available during package build, we could do the name -> id lookup at package build time. Would you like a patch implementing that? Helmut
