Hi
I've packaged DNF for Debian and would like to find someone to take over these
packages and maintain them as part of the distribution.
I'm not a DD and while I believe the packages to be of reasonable if not high
quality, I already have enough on my plate and know that I will not be able to
properly maintain them, keep up with upstream releases etc.
Point in case: while I did the original packaging more than a year, I only
updated this set of packages recently when they actually broke with newer Fedora
releases (i.e., they were too old to create newer Fedora changeroots when used
by mock).
== What is DNF? ==
For a long time, Fedora/RHEL/CentOS (and derivatives) used YUM as their default
package manager. DNF is a feature-rich YUM fork intended to replace it
eventually, using libsolv as its dependency solver, entered Fedora in version 18
as an option and has been its default package manager since version 22. RHEL 8,
based on Fedora 28, also already uses DNF as its default package manager.
== Why does Debian need DNF? ==
Debian already has packages for yum and mock. Building RPM packages on a Debian
system is a supported use case already utilized by a (probably rather small
amount) of users. That alone is normally not enough reason to introduce new
packages, but newer Fedora versions use features like boolean (or rich)
dependencies[0] that are plainly not supported by yum. Building such chroots
will flat out fail. DNF is now a hard dependency for supporting newer Fedora and
RHEL versions.
Without DNF, Debian would at some point lose the ability to be used a build host
for RPM packages.
Debian does NOT need DNF as an additional native package manager, but that
should be pretty clear. No sane user would (and should) try to mix dpkg/apt and
rpm/{yum,dnf} packages on a Debian system.
== Prerequisites ==
Most packages within unstable/sid are new enough.
The rpm source package needs a few rather trivial backports for new RPM tags -
submitted as https://bugs.debian.org/940114
The libsolv source package needs patches fixing its CMake integration, making it
usable with the "rpmdb-in-homedir" patch that is applied to Debian's rpm package
and enabling the COMPS feature - submitted as https://bugs.debian.org/889509
Eventually, I'd like Debian to completely drop the "rpmdb-in-homedir" patch
since it's causing more trouble than solving issues - a lengthy description of
why that is can be found in https://debugs.debian.org/794495 . While that is not
the case, we will have to patch libsolv to support that non-standard RPM behavior.
== Package List ==
=== libcomps 0.1.11-1 ===
Libcomps is library for structure-like manipulation of content in
comps XML files. Supports reading/writing XML files and structure
modifications.
Needed by: dnf
=== librepo 1.10.5-1 ===
A library providing C and Python (libcURL-like) APIs to
download repository metadata.
Needed by: libdnf
=== modulemd1 1.8.15-1 ===
A C library for manipulating module metadata files.
Needed by: libdnf, dnf
=== libdnf 0.35.3-1 ===
A library providing simplified C and Python APIs to libsolv.
Needed by: dnf
=== dnf 4.2.9-1 ===
Package manager forked from Yum, using libsolv as a dependency resolver.
Needed by: as explained above, also dnf-plugins-core
=== dnf-plugins-core 4.0.9-1 ===
This package enhances DNF with builddep, config-manager, copr, debug,
debuginfo-install, download, needs-restarting, repoclosure, repograph,
repomanage, reposync, changelog and repodiff commands.
Additionally provides generate_completion_cache passive plugin.
Needed by: mocks operation (builddep for instance) (not a proper dependency yet)
== Repository ==
Source and binaries (for unstable/sid, amd64) can be found at
https://packages.x2go.org/debian-test/pool/main/
If you want to test that, use something like
deb http://packages.x2go.org/debian-test sid main
deb-src http://packages.x2go.org/debian-test sid main
== Personal Note ===
I've been using DNF for the past one-and-a-half years for building RPM packages
on a Debian stretch machine. The proposed packages contain a few patches needed
for stretch integration (and stretch also needs changes to
gobject-introspection, glib and util-linux for DNF to build and work correctly).
I didn't want to rip them out and they don't cause trouble on newer-than-stretch
systems since their effect is essentially deactivated there. They are, however,
marked with "stretch" in the description and dropping them should be very easy.
They seemed to be very usable and stable for my use case - building RPM packages
via mock.
Mihai
[0] Debian/dpkg/apt has already known one of these "boolean(/rich) dependencies"
for quite some time - OR dependencies. RPM adds further ones, like (A if B)
which pulls in package A if B is already installed on the user system while
installing the dependent package, (A if B else C), which is the but extended
with a ternary term and crazier ones like (A with B), which instructs the solver
to find ONE single package that fulfills both A and B. Confused? A and B need
not be actual packages, it's totally valid for them to be other expressions,
like fully virtual ones. RPM spec files can use any statement in Provides:
clauses - and those can either live in a specific namespace (e.g.,
"pkgconfig(rpm)", which looks for an "rpm" capability in the "pkgconfig"
namespace) or in the global namespace (e.g., "mta", as a virtual package
specification). Yes, it's complicated to understand and arguably error-prone
(for humans), but the usage of such expressions is abundant within the
repositories nowadays.
Attachment:
signature.asc
Description: OpenPGP digital signature