On Tue, Feb 19, 2019 at 7:06 AM Leigh Scott <leigh123linux@xxxxxxxxx> 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[1] 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[0] 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 wanted to. 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!). [0]: https://github.com/ascherer/debbuild [1]: http://smartpm.github.io/smart/ -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
