On Tue, Feb 19, 2019 at 7:06 AM Leigh Scott <leigh123linux(a)gmail.com> wrote:
> Greetings packagers,
> I know how important RPM is to the Fedora Project, but it breaks
> everything downstream and we'd be better off using DPKG as we should
> have from day one.
> I'm calling this initiative fedpkg: Fedora Embraces DPKG.
> A bit of background here: I build both RPMs and DEBs for $DAYJOB and
> until recently my workflow was quite painful because I needed extra steps
> between git checkout and git push that involves a VM, because what we
> ship as apt is in reality apt-rpm.
Perhaps you could post a request to Debian devel-list to switch to RPM ;-)
I know this is a joke, but I'm going to answer this seriously anyway,
because it's an interesting exercise. :)
Well, one of the two package managers for Debian already supports RPM:
smart. Gustavo Niemeyer wrote smart to support multiple low level
package managers after dealing with the frustration of apt back then,
and it still retains that facility today. Smart still works and is
present in Debian and Ubuntu.
The other, apt, needs someone to contribute the rpm backend. The basic
scaffolding was added a little over a decade ago (ironically, after
Gustavo gave up and started developing smart), and most of the
rpm-specific concepts (like Obsoletes dep clause) are supported in
Debian apt but are completely unused. The librpm code in apt-rpm is
mostly in its own sources, but it would need some rejiggering to plug
into the current apt, as the internal APIs have been shuffled around a
bit. The apt-rpm upstream maintainer is still around on this mailing
list, and could probably help with this if someone expressed interest
in trying to do this. :)
Another bit would be a way for debhelper to emit a correctly formed
spec file to pass to rpmbuild, or an application built on top of
librpmbuild and librpmsign to allow a custom frontend for building
RPMs. Alternatively, if they wanted to drop dh automagic, then
debbuild can be used as a means of supporting building debs using
the RPM spec file format, giving a path to transition in that manner
too. Given Debian's culture, I would expect that a rpm building
frontend would need to be built rather than getting people to
transition to spec files.
Most likely, they'd want a way for rpm to accept debs and process
them. This in itself would probably not be difficult, since it's just
another archive format. In fact, there was a variant of rpm that could
do this, so it's not impossible. Once they have that, then it's just a
matter of churning things over, supporting both archive formats
indefinitely, or even working to develop a new unified format to
address pain points of both.
Alternatively, a plugin for rpm and a hook for dpkg could be written
so that the two package managers know what each are doing. The rpmdb
information would be exported to /var/lib/dpkg/status, and dpkg
actions would be written into the rpmdb with a key to indicate it was
from dpkg. That would give them a path to wind down usage of dpkg/deb
and switch things over to rpm. My understanding is that this has
actually been done before for supporting migrations both ways by
various people, but the code for those things was never released.
So if someone wanted to actually seriously propose this in Debian, it
*could* be done. But a strategy for the tooling needs to be addressed
first. I provided a couple of ideas of how someone could do it if they
The assumption, of course, is that Debian would want to preserve the
average user experience, which means not switching away from apt as
their primary package manager interface (even if I think DNF is
light-years ahead of it!).
真実はいつも一つ！/ Always, there's only one truth!