Cyril Brulebois:
Control: tag -1 pendingNiels Thykier <ni...@thykier.net> (2025-01-04):The switch has already been flipped (dpkg/1.22.13).I knew I should have skipped that part, as quickly skimming for “root” didn't turn up a hit on R³ obviously… :) (Hindsight, always 20/20.)Note it can in theory also cause wrong ownership in produced artifacts. Anything build by `dh_builddeb` will be sanitized correctly, but as I recall `debian-installer` does an extra non-deb artifact, which might want some review for builds *without* this patch (it might leak the building users name/uid into tarballs, etc.).You're absolutely right. I've just confirmed this by running `tar tf` on the generated -images tarball, and while *that* doesn't mention uid/gid information, those are of course encoded in the tarball: `tar tfv` can be used to verify that. Plenty of “kibi:kibi” in there without the patch.
If the tarball only needs `root:root` ownership, passing --owner root:0 --group root:0to tar will also work without `fakeroot` (that is basically how `dpkg-deb` solves this behind the scenes). I do not know that is the "only" blocker for going full `Rules-Requires-Root: no`. Though, if you can go full `Rules-Requires-Root: no`, then #1091085 would stop being a d-i problem. :)
With the patch applied, everything should go back to how it was previously, since `fakeroot` will reappear where it used to be.Indeed, back to “root:root” with the MR merged, thanks! And while I'm not debugging *that* today, I'm still seeing things like this, so I suppose the combination of the dpkg update + merging the MR indeed maintains the status quo regarding #1091085: libfakeroot internal error: payload not recognized! libfakeroot internal error: payload not recognized!
I would assume so. Using `Rules-Requires-Root: binary-targets` is exactly the old behavior. I have not touched anything on the `fakeroot` side in this transition, so it should work exactly as well (or bad) as it used to.
Super, will do. I was afraid this (like shim) would be a "here be dragons", […]Sorry about that… Cheers,
No worries. :) Best regards, Niels
OpenPGP_signature.asc
Description: OpenPGP digital signature
