Bug#1004863: Bootstrapping a Fedora produces a system with an empty package database
On Mon, 22 Apr 2024 15:38:00 +0100 Luca Boccassi wrote: > On Sat, 20 Apr 2024 20:48:06 +0100 Luca Boccassi > wrote: > > On Mon, 15 Apr 2024 at 10:34, Peter Pentchev > wrote: > > > > > > On Sun, Apr 14, 2024 at 07:39:54PM +0100, Luca Boccassi wrote: > > > > > Le 2/13/22 à 09:00, Mihai Moldovan a écrit : > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > I fully agree on removing the RPM patch that causes all of our > issues > > > > > on packages depending on it. If needed, I'm willing to be part > of > > > > > reviewing what would be the impact of returning to a standard > RPM > > > > > package on Debian and to help into solving those issues. Don't > > > > > hesitate to ping me for that. > > > > > > > > I think the time has come to drop the RPM Debian-specific patches > and > > > > avoid these workarounds altogether. > > > > > > > > Once upon a time it made sense to redirect the RPM DB, and to go > out of > > > > our way to stop users installing RPMs locally, when RPMs were > popular > > > > as a way to distribute upstream applications. > > > > > > > > Nowadays, the most common way to distribute upstream apps is via > > > > Flatpak/Appimage/etc, or (thanks to Ubuntu's popularity) via deb > > > > repositories, so the chances someone tries to 'sudo rpm -i > foo.rpm' are > > > > very low. > > > > > > > > The main use of having rpm/dnf/zypper in Debian is not to convert > RPMs > > > > with Alien or so, but it's to be able to do cross-distribution > > > > bootstraps and image building using native tools, like we do in > mkosi > This is now in experimental, unless I hear something I'll upload to > unstable during the weekend. Uploaded to unstable. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1004863: Bootstrapping a Fedora produces a system with an empty package database
On Sat, 20 Apr 2024 20:48:06 +0100 Luca Boccassi wrote: > On Mon, 15 Apr 2024 at 10:34, Peter Pentchev wrote: > > > > On Sun, Apr 14, 2024 at 07:39:54PM +0100, Luca Boccassi wrote: > > > > Le 2/13/22 à 09:00, Mihai Moldovan a écrit : > > > > > > > > > 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 > > > > > > > > > > > > > I fully agree on removing the RPM patch that causes all of our issues > > > > on packages depending on it. If needed, I'm willing to be part of > > > > reviewing what would be the impact of returning to a standard RPM > > > > package on Debian and to help into solving those issues. Don't > > > > hesitate to ping me for that. > > > > > > I think the time has come to drop the RPM Debian-specific patches and > > > avoid these workarounds altogether. > > > > > > Once upon a time it made sense to redirect the RPM DB, and to go out of > > > our way to stop users installing RPMs locally, when RPMs were popular > > > as a way to distribute upstream applications. > > > > > > Nowadays, the most common way to distribute upstream apps is via > > > Flatpak/Appimage/etc, or (thanks to Ubuntu's popularity) via deb > > > repositories, so the chances someone tries to 'sudo rpm -i foo.rpm' are > > > very low. > > > > > > The main use of having rpm/dnf/zypper in Debian is not to convert RPMs > > > with Alien or so, but it's to be able to do cross-distribution > > > bootstraps and image building using native tools, like we do in mkosi > > > (and in other tools as well). > > > > > > So these patches to print warnings and divert the database and so on > > > are a hindrance. > > > > > > Hence, for Trixie I think we should just drop them all. > > > > > > It should also make it easier to maintain the RPM stack, which has > > > languished. We are trying to move everything under the RPM Team Salsa > > > org, which should also help. > > > > > > If there are any objections please speak up. > > > > I've thought about making this change at least once a year, but > > I have always been, hm, should I say "too careful" (when of course > > I actually mean "too scared")... so if you feel the time has come, > > yeah, go ahead! This is now in experimental, unless I hear something I'll upload to unstable during the weekend. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1004863: Bootstrapping a Fedora produces a system with an empty package database
On Mon, 15 Apr 2024 at 10:34, Peter Pentchev wrote: > > On Sun, Apr 14, 2024 at 07:39:54PM +0100, Luca Boccassi wrote: > > > Le 2/13/22 à 09:00, Mihai Moldovan a écrit : > > > > > > > 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 > > > > > > > > > > I fully agree on removing the RPM patch that causes all of our issues > > > on packages depending on it. If needed, I'm willing to be part of > > > reviewing what would be the impact of returning to a standard RPM > > > package on Debian and to help into solving those issues. Don't > > > hesitate to ping me for that. > > > > I think the time has come to drop the RPM Debian-specific patches and > > avoid these workarounds altogether. > > > > Once upon a time it made sense to redirect the RPM DB, and to go out of > > our way to stop users installing RPMs locally, when RPMs were popular > > as a way to distribute upstream applications. > > > > Nowadays, the most common way to distribute upstream apps is via > > Flatpak/Appimage/etc, or (thanks to Ubuntu's popularity) via deb > > repositories, so the chances someone tries to 'sudo rpm -i foo.rpm' are > > very low. > > > > The main use of having rpm/dnf/zypper in Debian is not to convert RPMs > > with Alien or so, but it's to be able to do cross-distribution > > bootstraps and image building using native tools, like we do in mkosi > > (and in other tools as well). > > > > So these patches to print warnings and divert the database and so on > > are a hindrance. > > > > Hence, for Trixie I think we should just drop them all. > > > > It should also make it easier to maintain the RPM stack, which has > > languished. We are trying to move everything under the RPM Team Salsa > > org, which should also help. > > > > If there are any objections please speak up. > > I've thought about making this change at least once a year, but > I have always been, hm, should I say "too careful" (when of course > I actually mean "too scared")... so if you feel the time has come, > yeah, go ahead! > > G'luck, > Peter If there are no objections, I will do this next weekend.
Bug#1004863: Bootstrapping a Fedora produces a system with an empty package database
On Sun, Apr 14, 2024 at 07:39:54PM +0100, Luca Boccassi wrote: > > Le 2/13/22 à 09:00, Mihai Moldovan a écrit : > > > > > 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 > > > > > > > I fully agree on removing the RPM patch that causes all of our issues > > on packages depending on it. If needed, I'm willing to be part of > > reviewing what would be the impact of returning to a standard RPM > > package on Debian and to help into solving those issues. Don't > > hesitate to ping me for that. > > I think the time has come to drop the RPM Debian-specific patches and > avoid these workarounds altogether. > > Once upon a time it made sense to redirect the RPM DB, and to go out of > our way to stop users installing RPMs locally, when RPMs were popular > as a way to distribute upstream applications. > > Nowadays, the most common way to distribute upstream apps is via > Flatpak/Appimage/etc, or (thanks to Ubuntu's popularity) via deb > repositories, so the chances someone tries to 'sudo rpm -i foo.rpm' are > very low. > > The main use of having rpm/dnf/zypper in Debian is not to convert RPMs > with Alien or so, but it's to be able to do cross-distribution > bootstraps and image building using native tools, like we do in mkosi > (and in other tools as well). > > So these patches to print warnings and divert the database and so on > are a hindrance. > > Hence, for Trixie I think we should just drop them all. > > It should also make it easier to maintain the RPM stack, which has > languished. We are trying to move everything under the RPM Team Salsa > org, which should also help. > > If there are any objections please speak up. I've thought about making this change at least once a year, but I have always been, hm, should I say "too careful" (when of course I actually mean "too scared")... so if you feel the time has come, yeah, go ahead! G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1004863: Bootstrapping a Fedora produces a system with an empty package database
> Le 2/13/22 à 09:00, Mihai Moldovan a écrit : > > > 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 > > > > I fully agree on removing the RPM patch that causes all of our issues > on packages depending on it. If needed, I'm willing to be part of > reviewing what would be the impact of returning to a standard RPM > package on Debian and to help into solving those issues. Don't > hesitate to ping me for that. I think the time has come to drop the RPM Debian-specific patches and avoid these workarounds altogether. Once upon a time it made sense to redirect the RPM DB, and to go out of our way to stop users installing RPMs locally, when RPMs were popular as a way to distribute upstream applications. Nowadays, the most common way to distribute upstream apps is via Flatpak/Appimage/etc, or (thanks to Ubuntu's popularity) via deb repositories, so the chances someone tries to 'sudo rpm -i foo.rpm' are very low. The main use of having rpm/dnf/zypper in Debian is not to convert RPMs with Alien or so, but it's to be able to do cross-distribution bootstraps and image building using native tools, like we do in mkosi (and in other tools as well). So these patches to print warnings and divert the database and so on are a hindrance. Hence, for Trixie I think we should just drop them all. It should also make it easier to maintain the RPM stack, which has languished. We are trying to move everything under the RPM Team Salsa org, which should also help. If there are any objections please speak up. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1004863: Bootstrapping a Fedora produces a system with an empty package database
On Sat, Feb 12, 2022 at 08:51:01PM +0100, Enrico Zini 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. I tested, and I confirm that this works: dnf -c "$CONFFILE" -y --disablerepo=* --enablerepo=chroot-base --disableplugin=* \ --installroot="$DESTDIR" --releasever="$VERSION" install if [ -d "$DESTDIR/root/.rpmdb" ]; then rm -rf "$DESTDIR/var/lib/rpm" mv "$DESTDIR/root/.rpmdb" "$DESTDIR/var/lib/rpm" systemd-nspawn -D "$DESTDIR" -- /usr/bin/rpmdb --rebuilddb fi I wonder where would be the right place to document this. README.Debian maybe? Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Bug#1004863: Bootstrapping a Fedora produces a system with an empty package database
On Sun, Feb 13, 2022 at 10:27:33AM +0100, Frédéric Pierret wrote: > I fully agree on removing the RPM patch that causes all of our issues on > packages depending on it. If needed, I'm willing to be part of reviewing > what would be the impact of returning to a standard RPM package on Debian > and to help into solving those issues. Don't hesitate to ping me for that. I'd be glad to review and sponsor uploads as well. "btw", we should update dnf for bookworm too! > With respect to the original issue, correct me if I'm wrong, but the severity > of the bug has marked DNF to be removed. while this is not wrong, it's also true that I lowered the severity of the bug and thus the autoremoval procedure has been stopped. > DNF works for at least simple actions > like downloading packages from repositories. For example, we use it in Qubes > OS > in order to download updates for a Fedora system configuration from a Debian > system. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Never waste a crisis. signature.asc Description: PGP signature
Bug#1004863: Bootstrapping a Fedora produces a system with an empty package database
Hello, Le 2/13/22 à 09:00, Mihai Moldovan a écrit : 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 I fully agree on removing the RPM patch that causes all of our issues on packages depending on it. If needed, I'm willing to be part of reviewing what would be the impact of returning to a standard RPM package on Debian and to help into solving those issues. Don't hesitate to ping me for that. With respect to the original issue, correct me if I'm wrong, but the severity of the bug has marked DNF to be removed. DNF works for at least simple actions like downloading packages from repositories. For example, we use it in Qubes OS in order to download updates for a Fedora system configuration from a Debian system. Best regards, Frédéric OpenPGP_signature Description: OpenPGP digital signature
Bug#1004863: Bootstrapping a Fedora produces a system with an empty package database
* 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
Bug#1004863: Bootstrapping a Fedora produces a system with an empty package database
On Sat, Feb 12, 2022 at 06:51:26PM +0100, Mihai Moldovan wrote: > I can offer a workaround, though: the installing user (probably root?) should > have an .rpmdb directory in its home directory. After creating the initial > chroot, IN THE CHROOT, move this directory (/root/.rpmdb, if I remember > correctly) to /var/lib/rpm and execute /usr/bin/rpmdb --rebuilddb. Afterwards, > all installed packages should be accounted for in the chroot. 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. 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 apologize for the mess, but accounting for the already-broken RPM package > was > all I could do for the initial packaging of DNF. I don't think there's anything to apologise for, and thanks for taking care of these packages! 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. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Bug#1004863: Bootstrapping a Fedora produces a system with an empty package database
* On 2/11/22 1:57 PM, Holger Levsen wrote: > On Fri, Feb 11, 2022 at 01:33:08PM +0100, Enrico Zini wrote: >>> However I've downgraded it to important as eg Qubes 4.1 uses dnf on Debian >>> to >>> download upgrades for dom0, which is Fedora based. So the package is >>> certainly >>> not unusable for everyone, thus downgrading severity... >> Fair enough: it might be just a matter of documenting that dnf cannot be >> used to boostrap an RPM-based distribution from a Debian system. As outlined by the others, that's not completely true. It *can* be used for bootstrapping a system, the installed packages just won't be visible within the bootstrapped system. It's broken in some aspects, but crucially, it's not a bug in the DNF package itself. I can offer a workaround, though: the installing user (probably root?) should have an .rpmdb directory in its home directory. After creating the initial chroot, IN THE CHROOT, move this directory (/root/.rpmdb, if I remember correctly) to /var/lib/rpm and execute /usr/bin/rpmdb --rebuilddb. Afterwards, all installed packages should be accounted for in the chroot. > there's also " #794495 Mock fails to track installed packages" and > "#923352 RFA: rpm -- package manager for RPM" plus on I've just learned > on #qubes that Qubes has to work around the rpmdb location difference > as well... #794495 was the first issue I linked. This rpmdb-in-homedir patch has caused me a lot of grief over the past few years and we have to patch pretty much every software that is based upon RPM to either undo the damage caused by it or at least work it around. To give a bit of insight, as far as I've understood, the reason for having this patch is sound - it deliberately breaks RPM so that it's not used as a system package manager on Debian systems. Instead, main functionality is supposed to be retained for very specific cases like using alien to convert RPM packages to DEB packages. While the idea might be noble, it's easy to undo the change (just edit the dbpath component in the system-level rpm configuration file) and causing a lot more trouble than it's worth having. However, the RPM package is up for adoption, so it doesn't have a proper maintainer, which means that the issue is not getting traction. Even if it had one, undoing the patch is a bit tricky, since it requires checking RPM's users (like alien and... I think there's also some perl stuff as part of alien that uses this?) to make sure that dropping it doesn't break alien in unexpected ways. Especially, we don't want to inadvertently install packages as part of the conversion. I apologize for the mess, but accounting for the already-broken RPM package was all I could do for the initial packaging of DNF. Mihai OpenPGP_signature Description: OpenPGP digital signature
Bug#1004863: Bootstrapping a Fedora produces a system with an empty package database
On Fri, Feb 11, 2022 at 01:33:08PM +0100, Enrico Zini wrote: > > However I've downgraded it to important as eg Qubes 4.1 uses dnf on Debian > > to > > download upgrades for dom0, which is Fedora based. So the package is > > certainly > > not unusable for everyone, thus downgrading severity... > Fair enough: it might be just a matter of documenting that dnf cannot be > used to boostrap an RPM-based distribution from a Debian system. there's also " #794495 Mock fails to track installed packages" and "#923352 RFA: rpm -- package manager for RPM" plus on I've just learned on #qubes that Qubes has to work around the rpmdb location difference as well... -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ When this virus is over, I still want some of you all to stay away from me. signature.asc Description: PGP signature
Bug#1004863: Bootstrapping a Fedora produces a system with an empty package database
On Fri, Feb 11, 2022 at 06:38:16AM +0100, Mihai Moldovan wrote: > While Debian's rpm utility uses a homedir-based RPMDB, nothing else, > especially > not Fedora, expects that and, since dnf uses the system-version of RPM to > bootstrap, you'll run into exactly such issues. > > I can't do anything about that, other than try to NMU a version of RPM that > has > this patch removed, but that might break tools like alien and I'm not very > interested in spending a lot of time on that. On Fri, Feb 11, 2022 at 12:23:52PM +, Holger Levsen wrote: > However I've downgraded it to important as eg Qubes 4.1 uses dnf on Debian to > download upgrades for dom0, which is Fedora based. So the package is certainly > not unusable for everyone, thus downgrading severity... Fair enough: it might be just a matter of documenting that dnf cannot be used to boostrap an RPM-based distribution from a Debian system. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini
Bug#1004863: Bootstrapping a Fedora produces a system with an empty package database
control: severity -1 important On Wed, Feb 02, 2022 at 06:05:24PM +0100, Enrico Zini wrote: > thank you for packaging dnf in Debian! thank you for filing this bug report, Enrico! However I've downgraded it to important as eg Qubes 4.1 uses dnf on Debian to download upgrades for dom0, which is Fedora based. So the package is certainly not unusable for everyone, thus downgrading severity... -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ People call vaccine mandates "Orwellian" even though Orwell died at 46 of tuberculosis, which is now preventable with a vaccine. signature.asc Description: PGP signature
Bug#1004863: Bootstrapping a Fedora produces a system with an empty package database
* On 2/2/22 6:05 PM, Enrico Zini wrote: > I'm trying to use dnf to bootstrap rpm-based chroots, which seems to > work, but the rpm package database on the resulting distribution is > empty, as in, `rpm -qa` returns no output, and `rpm -q` on any package > complains that it is not installed. The actual files that are supposed > to be in the package are indeed present in the chroot. This is, AFAIR, an issue caused by Debian's patching of the RPM tools (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794495 ) While Debian's rpm utility uses a homedir-based RPMDB, nothing else, especially not Fedora, expects that and, since dnf uses the system-version of RPM to bootstrap, you'll run into exactly such issues. I can't do anything about that, other than try to NMU a version of RPM that has this patch removed, but that might break tools like alien and I'm not very interested in spending a lot of time on that. Another issue is that I'm still using my rather old dnf/mock packages on Debian Stretch and have never upgraded to anything newer yet. I've had to specifically patch dnf to support this weird 'rpmdb-in-homedir' construct, but packages installed as part of the bootstrapping procedure will NEVER be seen by the bootstrapped system, since their RPM version uses the usual, global RPMDB path of /var/lib/rpm. Sorry to shift the blame in such a fashion. Mihai OpenPGP_signature Description: OpenPGP digital signature
Bug#1004863: Bootstrapping a Fedora produces a system with an empty package database
Package: dnf Version: 4.5.2-6 Severity: serious Hello, thank you for packaging dnf in Debian! I'm trying to use dnf to bootstrap rpm-based chroots, which seems to work, but the rpm package database on the resulting distribution is empty, as in, `rpm -qa` returns no output, and `rpm -q` on any package complains that it is not installed. The actual files that are supposed to be in the package are indeed present in the chroot. I'm attaching outputs of the same command as run on my Debian Bullseye system and one I made on a Fedora 34 system. The output seems the same (sadly I had different terminal sizes which make diffing a bit awkward), but at the end, the outcome of rpm commands in the chroot differ. I'm assuming this is an issue of dnf as distributed in Debian, since the same command on Fedora works, but that is a guess from someone with no knowledge of dnf workings. Running `/usr/bin/rpmdb --rebuilddb` doesn't change the situation, and `rpm -qa` keeps returning empty output. Steps to reproduce: # mkdir test # cat > test.repo [chroot-base] name=Linux $releasever - $basearch baseurl=http://download.fedoraproject.org/pub/fedora/linux/releases/34/Everything/$basearch/os/ enabled=1 gpgcheck=0 # /usr/bin/dnf -c test.repo -y '--disablerepo=*' --enablerepo=chroot-base '--disableplugin=*' --installroot=$(readlink -f test) --releasever=34 install bash vim-minimal dnf rootfiles git dbus [...] Complete! # chroot test [root@host /]# rpm -qa [root@host /]# Thank you, Enrico -- System Information: Debian Release: 11.2 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-10-amd64 (SMP w/4 CPU threads) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dnf depends on: ii dnf-data 4.5.2-6 ii libmodulemd2 2.12.0-1 ii python3 3.9.2-3 ii python3-dbus 1.2.16-5 ii python3-dnf 4.5.2-6 ii sqlite3 3.34.1-3 dnf recommends no packages. dnf suggests no packages. -- no debconf information dnf-on-fedora43.log.gz Description: application/gzip dnf-on-debian-bullseye.log.gz Description: application/gzip
