* 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

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

Reply via email to