Hi Michal
I don't want to be condescending, but can we please, pretty-please stop breaking
rpm in Debian?
I understand that rpm is not intended to be used as a package manager on Debian
systems, but the rpmdb-in-homedir patch does more harm than good, causing
trouble in totally legitimate use cases as described in this bug report.
Users should be educated and preferably not even try to install RPM packages in
the first place, but putting the rpmdb into a user's home directory won't really
do any good.
Users wanting to use the rpm package within Debian to install rpm packages could
either just edit the global macro file and reset _dbpath to /var/lib/rpm, create
/var/lib/rpm and symlinks from ~/.rpmdb to that location or do even weirder
things.
The point is that even with this patch, rpm won't be unusable in the way you'd
like to make it, even if that requires very minor tweaking.
However, without tinkering, it breaks other software like mock or libsolv's RPM
backend. One could argue about the latter's use(fulness) on Debian, but breaking
mock is breaking a legitimate use case in which the rpm package really NEEDS to
install software correctly.
mock is some piece of software for building RPM packages (source or binaries) in
a chroot - quite like sbuild for Debian packages. I do use it a lot, but this
patch breaks mock in a very subtle way.
Looong explanation coming up: mock creates a new chroot and then uses an RPM
package manager (for instance yum, but potentially also dnf) to install a base
set of packages in there. Again, pretty much like debootstrap. For that to work,
the package manager is executed with the --installroot parameter, which
instructs it to essentially carry out all operations in the chroot - including
using the rpmdb in there. mock also sets HOME to /builddir, hence the rpmdb will
be created in /chroot/builddir/.rpmdb. Everything's fine until then, but then
mock fully deletes the home directory (within the chroot, of course) and
recreates it from scratch/skel. Boom, the rpmdb went bust.
This wasn't a huge problem per se, since in the worst case the package manager
would just install more packages than necessary when installing a source RPM's
build dependencies. Recently, however, rpm and dnf got support for rich
dependencies, which are also heavily used by Fedora at least (and likely will be
used by RHEL 8 as well). Such "rich dependencies" can be used to pull in
optional dependencies if a different package is already installed, for instance,
to automatically enhance functionality - notably, the "different package" need
not be any any direct or indirect dependency at all.
A real-world breaking example (with dnf, since yum doesn't support rich
dependencies, but I have dnf packages for Debian and would like to introduce
them at some point):
redhat-rpm-config has a dependency such as this:
Requires: (annobin if gcc)
This will pull in "annobin" as a dependency of redhat-rpm-config if the "gcc"
package is installed, but redhat-rpm-config does not depend upon "gcc".
What now happens is breakage: gcc is part of the base package set, so is
installed when creating the chroot. Since the rpmdb goes bust, the package
manager won't know it's installed and when a build-dependency (indirectly) pulls
in redhat-rpm-config, which is NOT part of base, it won't pull in annobin.
This then leads to build failures, since the annobin plugin is being used
unconditionally at build time. If it's not installed, builds fail.
Such breakage is subtle, and it's likely not the only thing to go haywire with
the patched rpm binaries.
Yes, I COULD go ahead and add .rpmdb to mock's config file option
"exclude_from_homedir_cleanup", but that would likely create even more problems.
Newer mock versions (currently not available in Debian, but I guess the mock
package will be updated eventually) can bootstrap the build system using the
system-provided package manager and then use the chroot-based package manager
for installing build dependencies. With the system rpm library/binary patched to
put the rpmdb in ${HOME}, but Fedoras/CentOS's not, we'd run into a very nice
/builddir/.rpmdb vs. /var/lib/rpm dance yet again.
Yet another argument: it makes other maintainer's lifes more difficult since
software like yum, dnf or libsolv have to be specifically patched to even work.
I can only re-iterate: Please consider dropping this patch.
Mihai
signature.asc
Description: OpenPGP digital signature
