Hello Sorry, I didn't read your long email. I just want to point out that rpm package is available for adoption, see https://bugs.debian.org/923352
--
Michal Čihař | https://cihar.com/ | https://weblate.org/
Mihai Moldovan píše v Čt 05. 09. 2019 v 15:55 +0200:
> 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: This is a digitally signed message part
