Mihai Moldovan <io...@ionic.de> 于2019年9月13日周五 下午11:46写道：
>
> 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
Just a story:
In the last year, I tried to rebootstrap Fedora for MIPS based on Debian,
and I was troubled lot due to difference of symbols of several libraries.
> 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.
>
--
YunQiang Su
