* On 2/12/22 8:51 PM, Enrico Zini wrote: > On Sat, Feb 12, 2022 at 06:51:26PM +0100, Mihai Moldovan wrote: > That's even better, then: it becomes a matter of documenting the > procedure to bootstrap an rpm-based distro from Debian: I can test it > and produce a draft HOWTO.
In the short term, yes. In the long term, I'd like to just get rid of the brokenness in Debian's RPM package and make this redundant. Please try the workaround I provided and see whether it fixes your initial issue. > Does this mean that boostrapping one rpm-based distro on another one > (like, bootstrapping a fedora34 on a fedora32 system) would require the > same workaround? I'm not sure if I understood this question correctly. Are you talking about a chroot in a chroot, so... a nested setup? In this case, no, because Fedora is not deliberately breaking their RPM package and if you bootstrap a newer Fedora chroot within an older Fedora chroot, the bootstrapping procedure will use the older Fedora's system DNF and RPM packages, which are working just fine. > I wonder if I've just made a 1:1 conceptual mapping between debootstrap > and this feature of dnf, and set expectations for the tool that the tool > isn't intended to provide for. No, you didn't. Bootstrapping an RPM-based distro changeroot, akin to Debootstrap for DEB-based distros, is pretty much what we need DNF in Debian for and is the only actual useful use case (but a very important one at that). DNF is a bit more powerful than debootstrap in the sense that you COULD, after the the initial chroot has been created, install new packages within the chroot from the outside system, but that's (currently) a bad idea due to Debian's RPM patch. To give a bit of context, this is the patch that causes all the trouble: https://salsa.debian.org/pkg-rpm-team/rpm/-/blob/master/debian/patches/rpmdb-in-home.patch It looks innocent, but leads to the mentioned issues and the need to patch a lot of other software so that it even works in the default configuration, the falldown looks like this: https://salsa.debian.org/debian/libsolv/-/blob/master/debian/patches/0002-repo_rpmdb-handle-dbpath-in-homedir.patch https://salsa.debian.org/fepitre/libdnf/-/blob/master/debian/patches/0005-Tell-libsolv-to-prefer-rpmdb-in-home-directory.patch https://salsa.debian.org/fepitre/libdnf/-/blob/master/debian/patches/0006-Add-rpmdb-in-home-directory-to-checksum-and-DNF-cont.patch Believe me when I say that I hate the original patch in Debian's RPM package very much. I've only seen now that Frédéric tried to upstream my libsolv patch at https://github.com/openSUSE/libsolv/pull/407 , but that it was rejected on the grounds that the upstream RPM developers already told Debian to stop breaking the package deliberately like... 20 years ago? While I understand the reasoning, I was confident that the patch can be upstreamed back when I wrote it, since it only changes behavior on Debian and leaves other distros/systems alone. Guess the upstream maintainer still didn't like it. I'm pretty sure that we can, at some point in the future, drop the offending patch from the RPM package and all of this will be redundant. It just requires a bit of work to make sure that older use cases (mostly alien) don't break due to this, which might require a bit of development on RPM itself. It's on my TODO list for very rainy and boring days, but unfortunately there's almost always a truckload of other things to do, so I keep dragging it out. Mihai
OpenPGP_signature
Description: OpenPGP digital signature
