Disable usrmerge for buster images?

[derobert]

The Buster images have symlinks from /bin → /usr/bin and /sbin → /usr/sbin. That's the default for d-i, but as discovered when the autobuilders had it enabled, builds done with it enabled may be broken. So it should probably be disabled in the docker images, just like on the autobuilders.

[tianon]

Hmm, interesting point -- honestly I can see making the argument here either way.

@aburch do you have any thoughts here you'd be willing to share on whether the Debian Docker images should follow d-i's or buildd chroot's lead on the subject of usrmerge? 🙏 ❤️

(or willing to CC anyone else who might be willing to help sort out what direction we should go here?)

[tianon]

(see also #12 for the last place we discussed this)

[derobert]

I'm guessing you're aware the technical committee is deciding on usrmerge for buster, which could of course make this request moot (e.g., if they decide against usrmerge in Buster). But anyway, presuming they don't, one thing that comes to mind is that the new-ish multi-stage builds let you build a usrmerge image from a non-usrmerge image without image size cost, or further bloating the git repository.

For example, here is one that works with Stretch (and probably buster, but I didn't test it since I don't have a non-usrmerge rootfs.tar.xz for it):

FROM scratch
ADD rootfs.tar.xz /
RUN mv /bin/* /usr/bin/            \
 && hash -r                        \
 && mv /sbin/* /usr/sbin           \
 && hash -r                        \
 && rmdir /bin                     \
 && rmdir /sbin                    \
 && ln -s /usr/bin /bin            \
 && ln -s /usr/sbin /sbin

FROM scratch
COPY --from=0 / /
CMD ["bash"]

... although that isn't fully reproducible (bloody timestamps), but then again it doesn't appear the existing images are, anyway. At least docker build generated a different image for stretch than I pulled from Docker hub (though it appears I'm using a different version of Docker).

[tianon]

Last I tried doing interesting things like that, ownership got clobbered, which I'm guessing is still the case?

[derobert]

Oh, you're right, groups are lost (and probably more too, but everything in rootfs is owned by root). And unfortunately ADD does not support --from, so can't just use a tarball like the way it works now.

The other thing that'd work would be to just manipulate rootfs.tar.xz before passing it to docker. Not sure which tools would be best to do that, though, or if that's an approach you'd even be interested in.

[derobert]

(It looks like https://github.com/moby/buildkit/blob/master/frontend/dockerfile/docs/experimental.md RUN --mount=type=bind… could be used in place of COPY, but I have no idea if/when that stops being experimental. I don't follow Docker development.)

[aburch]

@tianon: Hmm, a good question.

If people use it to build software that should be consumable outside of Docker (and in old Debian installations without merged-/usr), then opting out of merged-/usr is the safer choice for now just as for buildds; there will be many non-merged systems around for a while still.

Most advantages of having everything below /usr (isolating everything on a separate partition or applications such as ephermal systems) probably don't apply to Docker containers either.

Offering different variants (to provide both merged and non-merged base images) is probably not worth it IMHO.

[email protected] seems to be the right place to discuss this; not sure how many people follow these issues.

[tianon]

Thanks for your advice/thoughts (and your work in general); really appreciated ❤️

If people use it to build software that should be consumable outside of Docker (and in old Debian installations without merged-/usr), then opting out of merged-/usr is the safer choice for now just as for buildds; there will be many non-merged systems around for a while still.

It's definitely not a common use case of the image, but certainly something a non-zero number of folks will be using it for, so probably convincing enough anyhow. 😞

Most advantages of having everything below /usr (isolating everything on a separate partition or applications such as ephermal systems) probably don't apply to Docker containers either.

Full ack, makes sense.

Offering different variants (to provide both merged and non-merged base images) is probably not worth it IMHO.

Definitely agree, we already offer a lot of variations. 😄

[email protected] seems to be the right place to discuss this; not sure how many people follow these issues.

Yeah, that's fair, although I value your opinion on it more than that of the bikeshedding we're likely to get there, for what it's worth. 😅

I think the buildd argument is strong enough that we should follow suit. Perhaps if the default for the buildd variant ever switches back to merged-usr, then we can reconsider again. 😄

[tianon]

Implemented over in debuerreotype/debuerreotype#50 (which will close this and the adjustment will go out with the next debian image rebuild, which will likely be sometime after next weekend's stable release).

[zeha]

Could we get usrmerge enabled for the bullseye images, though?
Various low impact issues are starting to show up for non-merged installs, which probably nobody will track or fix. Personally I'd prefer it if new images would follow what the normal installer and debootstrap do by default, to avoid these cases.

[tianon]

@zeha sorry, somehow I missed this comment earlier 😬

I've posted a better long-form explanation of my thoughts on that over in #131 (comment) (and would prefer if we could continue the bullseye+ discussion over there 🙏 ❤️).