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.
It finally got enough on my nerves to locally build the things I needed and after a month I have already amortized my efforts with the time I save not having to deal with needless extra hoops.
In order to successfully build debs on Fedora I needed 4 packages that I'm now submitting for review:
https://bugzilla.redhat.com/show_bug.cgi?id=gnu-config https://bugzilla.redhat.com/show_bug.cgi?id=strip-nondeterminism https://bugzilla.redhat.com/show_bug.cgi?id=sbuild https://bugzilla.redhat.com/show_bug.cgi?id=apt
I need more than reviews here.
Three of those packages are heavy on Perl code, and I'm not a Perl Monk. I tried to CC perl-sig as per the guidelines [1] (also tried with the mailing list address) but bugzilla replied kindly:
CC: perl-sig did not match anything
Apt is a mix of C, Perl and C++ code, so I would be reassured if I could have a C++ co-maintainer too. I'm only a C developer so if something goes wrong outside of the C realm that would be helpful.
Two of those packages should be runtime dependencies of debhelper.
The current apt package should be renamed to apt-rpm, I will look up the procedure for that to happen. I understand that when someone sees they should run "apt-get install foo" somewhere on the web it's helpful for non-savvy users that this JustWorks(tm) [2], but apt-rpm is dead upstream and it shouldn't be advertised as apt.
I hope I CC'd everyone that should get this heads up, and hope to find help for the reviews and co-maintainership. The packaging does nothing fancy, there are quirks here and there but overall it was rather easy to put together. And of course I would be happy to help with reviews too in exchange.
And thanks again to the mock developers, its design is so much better than either sbuild or pdebuild that I barely have pain points left when it comes to RPM packaging.
Thanks, Dridi
[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/Perl/#_perl_sig [2] I'm not against apt-rpm in the base install for example
* Dridi Boukelmoune [19/02/2019 11:03] :
Three of those packages are heavy on Perl code, and I'm not a Perl Monk. I tried to CC perl-sig as per the guidelines [1] (also tried with the mailing list address) but bugzilla replied kindly:
CC: perl-sig did not match anything
The Perl SIG's mailing list address is perl-devel@lists.fedoraproject.org . This is a valid account in Bugzilla and should work.
Emmanuel
On Tue, Feb 19, 2019 at 11:20 AM Emmanuel Seyman emmanuel@seyman.fr wrote:
- Dridi Boukelmoune [19/02/2019 11:03] :
Three of those packages are heavy on Perl code, and I'm not a Perl Monk. I tried to CC perl-sig as per the guidelines [1] (also tried with the mailing list address) but bugzilla replied kindly:
CC: perl-sig did not match anythingThe Perl SIG's mailing list address is perl-devel@lists.fedoraproject.org . This is a valid account in Bugzilla and should work.
Right, I tried perl-sig@lists.fedoraproject.org when perl-sig didn't work.
It's CC'd now, thanks.
Dridi
On Tue, Feb 19, 2019 at 5:05 AM Dridi Boukelmoune dridi.boukelmoune@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.
It finally got enough on my nerves to locally build the things I needed and after a month I have already amortized my efforts with the time I save not having to deal with needless extra hoops.
In order to successfully build debs on Fedora I needed 4 packages that I'm now submitting for review:
https://bugzilla.redhat.com/show_bug.cgi?id=gnu-config https://bugzilla.redhat.com/show_bug.cgi?id=strip-nondeterminism https://bugzilla.redhat.com/show_bug.cgi?id=sbuild https://bugzilla.redhat.com/show_bug.cgi?id=apt
I need more than reviews here.
Three of those packages are heavy on Perl code, and I'm not a Perl Monk. I tried to CC perl-sig as per the guidelines [1] (also tried with the mailing list address) but bugzilla replied kindly:
CC: perl-sig did not match anythingApt is a mix of C, Perl and C++ code, so I would be reassured if I could have a C++ co-maintainer too. I'm only a C developer so if something goes wrong outside of the C realm that would be helpful.
Two of those packages should be runtime dependencies of debhelper.
The current apt package should be renamed to apt-rpm, I will look up the procedure for that to happen. I understand that when someone sees they should run "apt-get install foo" somewhere on the web it's helpful for non-savvy users that this JustWorks(tm) [2], but apt-rpm is dead upstream and it shouldn't be advertised as apt.
I hope I CC'd everyone that should get this heads up, and hope to find help for the reviews and co-maintainership. The packaging does nothing fancy, there are quirks here and there but overall it was rather easy to put together. And of course I would be happy to help with reviews too in exchange.
And thanks again to the mock developers, its design is so much better than either sbuild or pdebuild that I barely have pain points left when it comes to RPM packaging.
For what it's worth, this was a terrible lede for this email. And having worked extensively with both package managers, I can sincerely tell you both are ugly as hell, but rpm is less ugly than dpkg. Thankfully, I don't need to go into the reasons why, because this is not actually about switching to dpkg and its completely terrible system.
If all you wanted was the rest of the tooling in so you can build Debian packages in Fedora, that's really not a problem. I made an apt-dpkg package a while ago and worked with APT upstream to make it build and have the tests work (mostly) on Fedora a couple of years ago. I imported it into COPR so you can see it: https://copr.fedorainfracloud.org/coprs/ngompa/apt-dpkg/build/860086/
Instead of renaming the apt package to apt-rpm, we can introduce the apt-dpkg package that conflicts with apt for your purposes.
I wish we could have the rpm backend integrated into the Debian upstream apt, but someone needs to drive that effort, and no one really cares anymore. It hasn't happened in the past due to frustrations with working with Debian upstream, and now it's diverged so much that they are separate upstreams. My understanding is that the current upstream developers are interested in an rpm backend, but they don't want to do any effort to make it happen.
Also, you can build debs using RPM spec files[1], if you're aware enough to handle the differences. :)
[1]: https://github.com/ascherer/debbuild
-- 真実はいつも一つ！/ Always, there's only one truth!
For what it's worth, this was a terrible lede for this email. And
I couldn't help it, my inner prankster insisted :)
having worked extensively with both package managers, I can sincerely tell you both are ugly as hell, but rpm is less ugly than dpkg.
Yes, I'm not saying that rpm is perfect, but at least I can wrap my head around the tooling, the installation process (in a broad sense) and the tools built on top like yum/dnf or mock.
The range of tools from dpkg to sbuild/pdebuild make little sense to me, even after gaining significant experience because of $DAYJOB.
Thankfully, I don't need to go into the reasons why, because this is not actually about switching to dpkg and its completely terrible system.
Apologies on behalf of my inner prankster :)
If all you wanted was the rest of the tooling in so you can build Debian packages in Fedora, that's really not a problem. I made an apt-dpkg package a while ago and worked with APT upstream to make it build and have the tests work (mostly) on Fedora a couple of years ago. I imported it into COPR so you can see it: https://copr.fedorainfracloud.org/coprs/ngompa/apt-dpkg/build/860086/
Instead of renaming the apt package to apt-rpm, we can introduce the apt-dpkg package that conflicts with apt for your purposes.
But I've been bit by "dnf install apt" in the past and I think we should stick to upstream naming.
I wish we could have the rpm backend integrated into the Debian upstream apt, but someone needs to drive that effort, and no one really cares anymore. It hasn't happened in the past due to frustrations with working with Debian upstream, and now it's diverged so much that they are separate upstreams. My understanding is that the current upstream developers are interested in an rpm backend, but they don't want to do any effort to make it happen.
Also, you can build debs using RPM spec files[1], if you're aware enough to handle the differences. :)
I'm not aware, and that probably wouldn't work for $DAYJOB.
Thanks for stepping up as a reviewer!
Dridi
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 ;-)
On Tue, Feb 19, 2019 at 7:06 AM Leigh Scott leigh123linux@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[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/
On Tue, 2019-02-19 at 11:03 +0100, Dridi Boukelmoune 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.
It finally got enough on my nerves to locally build the things I needed and after a month I have already amortized my efforts with the time I save not having to deal with needless extra hoops.
In order to successfully build debs on Fedora I needed 4 packages that I'm now submitting for review:
https://bugzilla.redhat.com/show_bug.cgi?id=gnu-config https://bugzilla.redhat.com/show_bug.cgi?id=strip-nondeterminism https://bugzilla.redhat.com/show_bug.cgi?id=sbuild https://bugzilla.redhat.com/show_bug.cgi?id=apt
I need more than reviews here.
Three of those packages are heavy on Perl code, and I'm not a Perl Monk. I tried to CC perl-sig as per the guidelines [1] (also tried with the mailing list address) but bugzilla replied kindly:
CC: perl-sig did not match anythingApt is a mix of C, Perl and C++ code, so I would be reassured if I could have a C++ co-maintainer too. I'm only a C developer so if something goes wrong outside of the C realm that would be helpful.
Two of those packages should be runtime dependencies of debhelper.
The current apt package should be renamed to apt-rpm, I will look up the procedure for that to happen. I understand that when someone sees they should run "apt-get install foo" somewhere on the web it's helpful for non-savvy users that this JustWorks(tm) [2], but apt-rpm is dead upstream and it shouldn't be advertised as apt.
I hope I CC'd everyone that should get this heads up, and hope to find help for the reviews and co-maintainership. The packaging does nothing fancy, there are quirks here and there but overall it was rather easy to put together. And of course I would be happy to help with reviews too in exchange.
And thanks again to the mock developers, its design is so much better than either sbuild or pdebuild that I barely have pain points left when it comes to RPM packaging.
Thanks, Dridi
[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/Perl/#_perl_sig [2] I'm not against apt-rpm in the base install for example
TLDR , apt-rpm should be retired because nobody use it since more than 10 years .
I maintain a lot of debian package in Fedora but apt-debian still not on Official repos you can get it from my devel corp repo [1] My goal is make a system where rpm produce deb files , to allow Debian migrate from deb to rpm . rpm is much more powerful than Debian IMHO .
[1] https://copr.fedorainfracloud.org/coprs/sergiomb/debs/monitor/
I can build .deb packages in Fedora and download packages with apt- debian :
debuild -i -us -uc -b -d from https://wiki.archlinux.org/index.php/Creating_packages_for_other_distributio...
You may also need to override dh_shlibdeps by adding the following lines to debian/rules:
override_dh_shlibdeps:
dh_shlibdeps --dpkg-shlibdeps-params=--ignore-missing-info
and override_dh_strip_nondeterminism:
From [1] "I'd like propose retire this apt and fedora-package-config- apt".
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1462485
On Tue, Feb 19, 2019 at 7:40 AM Sérgio Basto sergio@serjux.com wrote:
On Tue, 2019-02-19 at 11:03 +0100, Dridi Boukelmoune 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.
It finally got enough on my nerves to locally build the things I needed and after a month I have already amortized my efforts with the time I save not having to deal with needless extra hoops.
In order to successfully build debs on Fedora I needed 4 packages that I'm now submitting for review:
https://bugzilla.redhat.com/show_bug.cgi?id=gnu-config https://bugzilla.redhat.com/show_bug.cgi?id=strip-nondeterminism https://bugzilla.redhat.com/show_bug.cgi?id=sbuild https://bugzilla.redhat.com/show_bug.cgi?id=apt
I need more than reviews here.
Three of those packages are heavy on Perl code, and I'm not a Perl Monk. I tried to CC perl-sig as per the guidelines [1] (also tried with the mailing list address) but bugzilla replied kindly:
CC: perl-sig did not match anythingApt is a mix of C, Perl and C++ code, so I would be reassured if I could have a C++ co-maintainer too. I'm only a C developer so if something goes wrong outside of the C realm that would be helpful.
Two of those packages should be runtime dependencies of debhelper.
The current apt package should be renamed to apt-rpm, I will look up the procedure for that to happen. I understand that when someone sees they should run "apt-get install foo" somewhere on the web it's helpful for non-savvy users that this JustWorks(tm) [2], but apt-rpm is dead upstream and it shouldn't be advertised as apt.
I hope I CC'd everyone that should get this heads up, and hope to find help for the reviews and co-maintainership. The packaging does nothing fancy, there are quirks here and there but overall it was rather easy to put together. And of course I would be happy to help with reviews too in exchange.
And thanks again to the mock developers, its design is so much better than either sbuild or pdebuild that I barely have pain points left when it comes to RPM packaging.
Thanks, Dridi
[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/Perl/#_perl_sig [2] I'm not against apt-rpm in the base install for example
TLDR , apt-rpm should be retired because nobody use it since more than 10 years .
Unfortunately, I *do* use it occasionally when working on Linux distros that use apt-rpm, as only apt-rpm can process their repo metadata. There are still a few out there that use it. That said, Fedora's apt config package should probably be retired.
-- 真実はいつも一つ！/ Always, there's only one truth!
On Tue, 2019-02-19 at 08:21 -0500, Neal Gompa wrote:
On Tue, Feb 19, 2019 at 7:40 AM Sérgio Basto sergio@serjux.com wrote:
On Tue, 2019-02-19 at 11:03 +0100, Dridi Boukelmoune 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.
It finally got enough on my nerves to locally build the things I needed and after a month I have already amortized my efforts with the time I save not having to deal with needless extra hoops.
In order to successfully build debs on Fedora I needed 4 packages that I'm now submitting for review:
https://bugzilla.redhat.com/show_bug.cgi?id=gnu-config https://bugzilla.redhat.com/show_bug.cgi?id=strip-nondeterminism https://bugzilla.redhat.com/show_bug.cgi?id=sbuild https://bugzilla.redhat.com/show_bug.cgi?id=apt
I need more than reviews here.
Three of those packages are heavy on Perl code, and I'm not a Perl Monk. I tried to CC perl-sig as per the guidelines [1] (also tried with the mailing list address) but bugzilla replied kindly:
CC: perl-sig did not match anythingApt is a mix of C, Perl and C++ code, so I would be reassured if I could have a C++ co-maintainer too. I'm only a C developer so if something goes wrong outside of the C realm that would be helpful.
Two of those packages should be runtime dependencies of debhelper.
The current apt package should be renamed to apt-rpm, I will look up the procedure for that to happen. I understand that when someone sees they should run "apt-get install foo" somewhere on the web it's helpful for non-savvy users that this JustWorks(tm) [2], but apt- rpm is dead upstream and it shouldn't be advertised as apt.
I hope I CC'd everyone that should get this heads up, and hope to find help for the reviews and co-maintainership. The packaging does nothing fancy, there are quirks here and there but overall it was rather easy to put together. And of course I would be happy to help with reviews too in exchange.
And thanks again to the mock developers, its design is so much better than either sbuild or pdebuild that I barely have pain points left when it comes to RPM packaging.
Thanks, Dridi
[1]
https://docs.fedoraproject.org/en-US/packaging-guidelines/Perl/#_perl_sig
[2] I'm not against apt-rpm in the base install for example
TLDR , apt-rpm should be retired because nobody use it since more than 10 years .
Unfortunately, I *do* use it occasionally when working on Linux distros that use apt-rpm, as only apt-rpm can process their repo metadata. There are still a few out there that use it. That said, Fedora's apt config package should probably be retired.
Out of curiosity , what distro ? they have any update ? i.e. [1] last version is dated on 12-Jan-2008 ... seems a little old to me , anddon't see any update ...
[1] https://src.fedoraproject.org/rpms/apt/blob/master/f/apt.spec http://apt-rpm.org/testing/
-- 真実はいつも一つ！/ Always, there's only one truth!
On Tue, Feb 19, 2019 at 12:16 PM Sérgio Basto sergio@serjux.com wrote:
On Tue, 2019-02-19 at 08:21 -0500, Neal Gompa wrote:
On Tue, Feb 19, 2019 at 7:40 AM Sérgio Basto sergio@serjux.com wrote:
On Tue, 2019-02-19 at 11:03 +0100, Dridi Boukelmoune 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.
It finally got enough on my nerves to locally build the things I needed and after a month I have already amortized my efforts with the time I save not having to deal with needless extra hoops.
In order to successfully build debs on Fedora I needed 4 packages that I'm now submitting for review:
https://bugzilla.redhat.com/show_bug.cgi?id=gnu-config https://bugzilla.redhat.com/show_bug.cgi?id=strip-nondeterminism https://bugzilla.redhat.com/show_bug.cgi?id=sbuild https://bugzilla.redhat.com/show_bug.cgi?id=apt
I need more than reviews here.
Three of those packages are heavy on Perl code, and I'm not a Perl Monk. I tried to CC perl-sig as per the guidelines [1] (also tried with the mailing list address) but bugzilla replied kindly:
CC: perl-sig did not match anythingApt is a mix of C, Perl and C++ code, so I would be reassured if I could have a C++ co-maintainer too. I'm only a C developer so if something goes wrong outside of the C realm that would be helpful.
Two of those packages should be runtime dependencies of debhelper.
The current apt package should be renamed to apt-rpm, I will look up the procedure for that to happen. I understand that when someone sees they should run "apt-get install foo" somewhere on the web it's helpful for non-savvy users that this JustWorks(tm) [2], but apt- rpm is dead upstream and it shouldn't be advertised as apt.
I hope I CC'd everyone that should get this heads up, and hope to find help for the reviews and co-maintainership. The packaging does nothing fancy, there are quirks here and there but overall it was rather easy to put together. And of course I would be happy to help with reviews too in exchange.
And thanks again to the mock developers, its design is so much better than either sbuild or pdebuild that I barely have pain points left when it comes to RPM packaging.
Thanks, Dridi
[1]
https://docs.fedoraproject.org/en-US/packaging-guidelines/Perl/#_perl_sig
[2] I'm not against apt-rpm in the base install for example
TLDR , apt-rpm should be retired because nobody use it since more than 10 years .
Unfortunately, I *do* use it occasionally when working on Linux distros that use apt-rpm, as only apt-rpm can process their repo metadata. There are still a few out there that use it. That said, Fedora's apt config package should probably be retired.
Out of curiosity , what distro ? they have any update ? i.e. [1] last version is dated on 12-Jan-2008 ... seems a little old to me , anddon't see any update ...
ALT Linux and PCLinuxOS are two that use apt-rpm.
There's _slightly_ more life (but not much) in the Git repo for apt-rpm: https://gitlab.com/apt-rpm/apt-rpm
TLDR , apt-rpm should be retired because nobody use it since more than 10 years .
I maintain a lot of debian package in Fedora but apt-debian still not on Official repos you can get it from my devel corp repo [1] My goal is make a system where rpm produce deb files , to allow Debian migrate from deb to rpm . rpm is much more powerful than Debian IMHO .
[1] https://copr.fedorainfracloud.org/coprs/sergiomb/debs/monitor/
I can build .deb packages in Fedora and download packages with apt- debian :
debuild -i -us -uc -b -d from https://wiki.archlinux.org/index.php/Creating_packages_for_other_distributio...
That's the beauty of the DPKG ecosystem, you always have a myriad of seemingly same tools and they often lack consistency.
Should I use debuild, dpkg-buildpackage, or one of the two others?
With or without rules? Should I rely on debhelper?
The list goes on.
You may also need to override dh_shlibdeps by adding the following lines to debian/rules:
override_dh_shlibdeps:
dh_shlibdeps --dpkg-shlibdeps-params=--ignore-missing-info
Yes, that one needs an override on Fedora.
and override_dh_strip_nondeterminism:
That one should be solved by one of my package submissions.
From [1] "I'd like propose retire this apt and fedora-package-config- apt".
Again, I have no problem with apt-rpm if someone wants to maintain it and it keeps working, my problem is that it's called apt.
Dridi
On Tue, 2019-02-19 at 20:00 +0100, Dridi Boukelmoune wrote:
TLDR , apt-rpm should be retired because nobody use it since more than 10 years .
I maintain a lot of debian package in Fedora but apt-debian still not on Official repos you can get it from my devel corp repo [1] My goal is make a system where rpm produce deb files , to allow Debian migrate from deb to rpm . rpm is much more powerful than Debian IMHO .
[1] https://copr.fedorainfracloud.org/coprs/sergiomb/debs/monitor/
I can build .deb packages in Fedora and download packages with apt- debian :
debuild -i -us -uc -b -d from
https://wiki.archlinux.org/index.php/Creating_packages_for_other_distributio...
That's the beauty of the DPKG ecosystem, you always have a myriad of seemingly same tools and they often lack consistency.
Should I use debuild, dpkg-buildpackage, or one of the two others?
With or without rules? Should I rely on debhelper?
The list goes on.
You may also need to override dh_shlibdeps by adding the following lines to debian/rules:
override_dh_shlibdeps:
dh_shlibdeps --dpkg-shlibdeps-params=--ignore-missing-info
Yes, that one needs an override on Fedora.
and override_dh_strip_nondeterminism:
That one should be solved by one of my package submissions.
I'm the debhelper maintainer
where are your packages submissions ? (can you add me please )
I have reports that pbuilder works fine even in el7 (with packages of epel7)
From [1] "I'd like propose retire this apt and fedora-package- config- apt".
Again, I have no problem with apt-rpm if someone wants to maintain it and it keeps working, my problem is that it's called apt.
Dridi
I'm the debhelper maintainer
where are your packages submissions ? (can you add me please )
https://bugzilla.redhat.com/show_bug.cgi?id=gnu-config https://bugzilla.redhat.com/show_bug.cgi?id=strip-nondeterminism
I CC'd you just now. According to Neal we may not need to package GNU config, let's move the discussion in that ticket.
I have reports that pbuilder works fine even in el7 (with packages of epel7)
I have used pdebuild in the past on Fedora and maybe that one works, but I think I had to run pbuilder on an ubuntu system to build my base images and then use them on Fedora with pdebuild.
It's been a while.
With my package submissions, I'm finally able to do my deb packaging directly in my favorite OS :)
Dridi
On Tue, 19 Feb 2019 at 11:11, Dridi Boukelmoune dridi.boukelmoune@gmail.com wrote: [..]
Apt is a mix of C, Perl and C++ code, so I would be reassured if I could have a C++ co-maintainer too. I'm only a C developer so if something goes wrong outside of the C realm that would be helpful.
Doesn't matter in what kind of language is written PM. Probably you are not aware that but initially rpm it was written 100% in perl. Nevertheless forget about such change. DPKG technologically stopped evolving about +15 years ago and today rpm packages relies on many features never implemented in DPKG (not only on area of managing installed/upgraded software but building packages as well). In other words: move from rpm to dpkg would be only a lot of effort spent to make happier really small bunch of people increasing only effort for the rest of packagers and package consumers.
What I see which potentially could make a sense would be writing rpm backend to generate deb packages out of spec files. That would be beneficial for part of the Debian community the same way as using rpm spec files to build IPS packages on Solaris. Such goal is possible to archive the same way as in case of IPS by writing short wrapper like that on on http://pkgbuild.sf.net/ Fill free to code such tool .. you have already spec file parser and other bits written so >=80-90% necessary work is already done.
As long as it has nothing to do with Fedora for me EOT.
kloczek
On Tue, Feb 19, 2019 at 7:08 PM Tomasz Kłoczko kloczko.tomasz@gmail.com wrote:
On Tue, 19 Feb 2019 at 11:11, Dridi Boukelmoune dridi.boukelmoune@gmail.com wrote: [..]
Apt is a mix of C, Perl and C++ code, so I would be reassured if I could have a C++ co-maintainer too. I'm only a C developer so if something goes wrong outside of the C realm that would be helpful.
Doesn't matter in what kind of language is written PM. Probably you are not aware that but initially rpm it was written 100% in perl. Nevertheless forget about such change.
It does if things break during an upgrade and I have to patch it.
DPKG technologically stopped evolving about +15 years ago and today rpm packages relies on many features never implemented in DPKG (not only on area of managing installed/upgraded software but building packages as well). In other words: move from rpm to dpkg would be only a lot of effort spent to make happier really small bunch of people increasing only effort for the rest of packagers and package consumers.
My problem is that I want to improve my work experience when it comes to building debs and evolving packaging.
What I see which potentially could make a sense would be writing rpm backend to generate deb packages out of spec files.
What an alien concept, if you catch my drift... :p
That would be beneficial for part of the Debian community the same way as using rpm spec files to build IPS packages on Solaris. Such goal is possible to archive the same way as in case of IPS by writing short wrapper like that on on http://pkgbuild.sf.net/ Fill free to code such tool .. you have already spec file parser and other bits written so >=80-90% necessary work is already done.
As long as it has nothing to do with Fedora for me EOT.
kloczek
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
On Wed, Feb 20, 2019 at 11:04 AM Akarshan Biswas akarshan.biswas@gmail.com wrote:
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.
Doesn't we have flatpaks for that purpose?
No, that was a bad joke from my end, what I need is proper apt in Fedora to use sbuild.
Dridi
On Wed, 2019-02-20 at 11:46 +0100, Dridi Boukelmoune wrote:
No, that was a bad joke from my end, what I need is proper apt in Fedora to use sbuild.
If you also do the review-request for apt [1] it would be great dh-python also welcomed :) [2] The problem is apt is in use by apt-rpm and was not retired yet , we need use another name , my propose is apt-debian .
Thanks,
[1] https://copr-dist-git.fedorainfracloud.org/cgit/sergiomb/debs/apt.git/tree/a...
[2] https://copr-dist-git.fedorainfracloud.org/cgit/sergiomb/debs/dh-python.git/...
Dridi _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
On 2/20/19 5:19 PM, Sérgio Basto wrote:
On Wed, 2019-02-20 at 11:46 +0100, Dridi Boukelmoune wrote:
No, that was a bad joke from my end, what I need is proper apt in Fedora to use sbuild.
If you also do the review-request for apt [1] it would be great dh-python also welcomed :) [2] The problem is apt is in use by apt-rpm and was not retired yet , we need use another name , my propose is apt-debian .
Just FWIW, the fact that apt-rpm is still in Fedora is against the direct recommendation of the last upstream maintainer (as in, me).
It's been dead for ten years and is totally useless in todays Fedora with rich dependencies and all. Short of somebody stepping up to revive the upstream project, the only responsible action would be retiring it.
- Panu -
On Wed, Feb 20, 2019 at 4:30 PM Panu Matilainen pmatilai@redhat.com wrote:
On 2/20/19 5:19 PM, Sérgio Basto wrote:
On Wed, 2019-02-20 at 11:46 +0100, Dridi Boukelmoune wrote:
No, that was a bad joke from my end, what I need is proper apt in Fedora to use sbuild.
If you also do the review-request for apt [1] it would be great dh-python also welcomed :) [2] The problem is apt is in use by apt-rpm and was not retired yet , we need use another name , my propose is apt-debian .
Just FWIW, the fact that apt-rpm is still in Fedora is against the direct recommendation of the last upstream maintainer (as in, me).
It's been dead for ten years and is totally useless in todays Fedora with rich dependencies and all. Short of somebody stepping up to revive the upstream project, the only responsible action would be retiring it.
Oh, if upstream says so, I will look up the procedure to ask for a package to be retired. That's a first for me...
Thanks, Dridi
On Wed, 2019-02-20 at 16:33 +0100, Dridi Boukelmoune wrote:
On Wed, Feb 20, 2019 at 4:30 PM Panu Matilainen pmatilai@redhat.com wrote:
On 2/20/19 5:19 PM, Sérgio Basto wrote:
On Wed, 2019-02-20 at 11:46 +0100, Dridi Boukelmoune wrote:
No, that was a bad joke from my end, what I need is proper apt in Fedora to use sbuild.
If you also do the review-request for apt [1] it would be great dh-python also welcomed :) [2] The problem is apt is in use by apt-rpm and was not retired yet , we need use another name , my propose is apt-debian .
Just FWIW, the fact that apt-rpm is still in Fedora is against the direct recommendation of the last upstream maintainer (as in, me).
It's been dead for ten years and is totally useless in todays Fedora with rich dependencies and all. Short of somebody stepping up to revive the upstream project, the only responsible action would be retiring it.
Oh, if upstream says so, I will look up the procedure to ask for a package to be retired. That's a first for me...
That is not easy , the current procedure is ask for orphan it , if maintainer doesn't reply , we need open a un reponsive process for the maintainer , wait a lot of time , orphan the package , take the package and retire it .
On Wed, 2019-02-20 at 20:18 +0000, Sérgio Basto wrote:
On Wed, 2019-02-20 at 16:33 +0100, Dridi Boukelmoune wrote:
On Wed, Feb 20, 2019 at 4:30 PM Panu Matilainen < pmatilai@redhat.com> wrote:
On 2/20/19 5:19 PM, Sérgio Basto wrote:
On Wed, 2019-02-20 at 11:46 +0100, Dridi Boukelmoune wrote:
No, that was a bad joke from my end, what I need is proper apt in Fedora to use sbuild.
If you also do the review-request for apt [1] it would be great dh-python also welcomed :) [2] The problem is apt is in use by apt-rpm and was not retired yet , we need use another name , my propose is apt-debian .
Just FWIW, the fact that apt-rpm is still in Fedora is against the direct recommendation of the last upstream maintainer (as in, me).
It's been dead for ten years and is totally useless in todays Fedora with rich dependencies and all. Short of somebody stepping up to revive the upstream project, the only responsible action would be retiring it.
Oh, if upstream says so, I will look up the procedure to ask for a package to be retired. That's a first for me...
That is not easy , the current procedure is ask for orphan it , if maintainer doesn't reply , we need open a un reponsive process for the maintainer , wait a lot of time , orphan the package , take the package and retire it .
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
-- Sérgio M. B. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
On Wednesday, 20 February 2019 at 16:33, Dridi Boukelmoune wrote:
On Wed, Feb 20, 2019 at 4:30 PM Panu Matilainen pmatilai@redhat.com wrote:
On 2/20/19 5:19 PM, Sérgio Basto wrote:
On Wed, 2019-02-20 at 11:46 +0100, Dridi Boukelmoune wrote:
No, that was a bad joke from my end, what I need is proper apt in Fedora to use sbuild.
If you also do the review-request for apt [1] it would be great dh-python also welcomed :) [2] The problem is apt is in use by apt-rpm and was not retired yet , we need use another name , my propose is apt-debian .
Just FWIW, the fact that apt-rpm is still in Fedora is against the direct recommendation of the last upstream maintainer (as in, me).
It's been dead for ten years and is totally useless in todays Fedora with rich dependencies and all. Short of somebody stepping up to revive the upstream project, the only responsible action would be retiring it.
Oh, if upstream says so, I will look up the procedure to ask for a package to be retired. That's a first for me...
Wouldn't it be better to take over the existing apt package and switch it to the real apt? Announce that on the devel list and live happily ever after. ;)
Regards, Dominik
On 2/20/2019 7:29 AM, Panu Matilainen wrote:
On 2/20/19 5:19 PM, Sérgio Basto wrote:
On Wed, 2019-02-20 at 11:46 +0100, Dridi Boukelmoune wrote:
No, that was a bad joke from my end, what I need is proper apt in Fedora to use sbuild.
If you also do the review-request for apt [1] it would be great dh-python also welcomed :) [2] The problem is apt is in use by apt-rpm and was not retired yet , we need use another name , my propose is apt-debian .
Just FWIW, the fact that apt-rpm is still in Fedora is against the direct recommendation of the last upstream maintainer (as in, me).
It's been dead for ten years and is totally useless in todays Fedora with rich dependencies and all. Short of somebody stepping up to revive the upstream project, the only responsible action would be retiring it.
That may be the case for *Fedora*, but plenty of RPM-based distros don't use rich dependencies (optionally: yet), and .spec-writers may chose to avoid using them for maximal compatibility. That's not itself a reason to write it off.
-jc
On 2/21/19 8:22 PM, Japheth Cleaver wrote:
On 2/20/2019 7:29 AM, Panu Matilainen wrote:
On 2/20/19 5:19 PM, Sérgio Basto wrote:
On Wed, 2019-02-20 at 11:46 +0100, Dridi Boukelmoune wrote:
No, that was a bad joke from my end, what I need is proper apt in Fedora to use sbuild.
If you also do the review-request for apt [1] it would be great dh-python also welcomed :) [2] The problem is apt is in use by apt-rpm and was not retired yet , we need use another name , my propose is apt-debian .
Just FWIW, the fact that apt-rpm is still in Fedora is against the direct recommendation of the last upstream maintainer (as in, me).
It's been dead for ten years and is totally useless in todays Fedora with rich dependencies and all. Short of somebody stepping up to revive the upstream project, the only responsible action would be retiring it.
That may be the case for *Fedora*, but plenty of RPM-based distros don't use rich dependencies (optionally: yet), and .spec-writers may chose to avoid using them for maximal compatibility. That's not itself a reason to write it off.
Shipping dysfunctional software gives an impression of bad quality. But that's merely an image issue.
The real problem is (and I shouldn't have to spell it out on a devel list really) that this is software that accesses network, requires root to run and cannot even be contained by SELinux and the like because it by it's nature requires unlimited permissions. Said software is unmaintained for years and has any number of security vulnerabilities, some even known, that nobody is fixing. Those who can build the software by themselves from the source for their own specific needs can be expected to asses and deal with the risks involved, but shipping such software in a distro is just irresponsible.
- Panu -
On Wed, Feb 20, 2019 at 4:20 PM Sérgio Basto sergio@serjux.com wrote:
On Wed, 2019-02-20 at 11:46 +0100, Dridi Boukelmoune wrote:
No, that was a bad joke from my end, what I need is proper apt in Fedora to use sbuild.
If you also do the review-request for apt [1] it would be great dh-python also welcomed :) [2]
I don't do the reviews, I submitted the packages :)
But if you submit it, I will gladly do the review.
The problem is apt is in use by apt-rpm and was not retired yet , we need use another name , my propose is apt-debian .
None of the 3 maintainers of apt-rpm have replied to this thread yet.
What they can do if they insist in keeping apt-rpm in Fedora is to rename the source package:
https://fedoraproject.org/wiki/Package_Renaming_Process#Re-review_required
Dridi
On Wed, 2019-02-20 at 16:31 +0100, Dridi Boukelmoune wrote:
On Wed, Feb 20, 2019 at 4:20 PM Sérgio Basto sergio@serjux.com wrote:
On Wed, 2019-02-20 at 11:46 +0100, Dridi Boukelmoune wrote:
No, that was a bad joke from my end, what I need is proper apt in Fedora to use sbuild.
If you also do the review-request for apt [1] it would be great dh-python also welcomed :) [2]
I don't do the reviews, I submitted the packages :)
Yes you did the the review requests [1] if you have time and will you may do the same for apt-debian and dh-python , please .
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1678623 https://bugzilla.redhat.com/show_bug.cgi?id=1678619
On 19 Feb 2019, at 12:03, Dridi Boukelmoune dridi.boukelmoune@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.
DPKG solved the packaging problem, but was particularly inelegant doing so, primary because the goal at the time was to move from nothing to something. RPM was able to learn from the first attempt, and is far simpler and more robust.
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.
If I’m understanding you correctly are you trying to being Debian packages on a Fedora system?
I’m not seeing how a need like this justifies reengineering an entire software ecosystem.
Regards, Graham —
Hi Graham,
On Thu, Feb 21, 2019 at 1:23 PM Graham Leggett minfrin@sharp.fm wrote:
On 19 Feb 2019, at 12:03, Dridi Boukelmoune dridi.boukelmoune@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.
DPKG solved the packaging problem, but was particularly inelegant doing so, primary because the goal at the time was to move from nothing to something. RPM was able to learn from the first attempt, and is far simpler and more robust.
I need to apologize again for my bad joke.
I don't really like the DPKG/apt ecosystem, and wasn't implying that Fedora as a distribution should switch to DPKG (RPM is one of the reasons I'm using Fedora). Rather that we have an "apt" package that currently isn't upstream "apt" but dead upstream "apt-rpm" instead.
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.
If I’m understanding you correctly are you trying to being Debian packages on a Fedora system?
Yes, thanks to $EMPLOYER letting me use Fedora for $DAYJOB, I can use my favorite OS both personally and for work. And I do Debian packaging for my $DAYJOB.
I’m not seeing how a need like this justifies reengineering an entire software ecosystem.
Indeed, I only wish to replace one package by another, and add a couple more to improve the DPKG experience on Fedora. The fact that I don't need to switch systems to target either Debian/Ubuntu or RHEL/CentOS is a great bonus.
I'm trying to submit RPMs that I have been using locally to build Debs on Fedora \o/
Dridi
Its ok to have something that builds deb packages on Fedora, but in my opinion RPM is far more better then debian packages. Also the Dnf and yum package manager on Fedora are far more advanced than apt on Ubuntu and other Debian Based system. I have been using fedora for over 2 years now and I have never faced the package installation issues that I faced with apt and dpkg, for whatever unknown reasons, may be some corruption of package file, installation state Ubuntu's package manager gets erroneous to an unrecoverable state, and I being a normal desktop user wasn't able to restore the state, and had to reinstall the whole OS from scratch. dpkg/apt is good when it works, but when it breaks its unrecoverable. RPM , dnf/yum are more reliable.
On Tue, Jul 14, 2020 at 8:39 PM Dishant Pandya drpdishant@gmail.com wrote:
Its ok to have something that builds deb packages on Fedora, but in my opinion RPM is far more better then debian packages. Also the Dnf and yum package manager on Fedora are far more advanced than apt on Ubuntu and other Debian Based system. I have been using fedora for over 2 years now and I have never faced the package installation issues that I faced with apt and dpkg, for whatever unknown reasons, may be some corruption of package file, installation state Ubuntu's package manager gets erroneous to an unrecoverable state, and I being a normal desktop user wasn't able to restore the state, and had to reinstall the whole OS from scratch. dpkg/apt is good when it works, but when it breaks its unrecoverable. RPM , dnf/yum are more reliable.
That poor joke of mine keeps hitting home :)
Fedora remains an RPM-based system using DNF. What this change was about was really to allow using apt with deb packages. It makes it easier to pull more tools from the dpkg ecosystem like mock equivalent sbuild.
Nothing to worry about.
Cheers, Dridi
On Wed, Jul 15, 2020 at 4:29 AM Dridi Boukelmoune dridi.boukelmoune@gmail.com wrote:
On Tue, Jul 14, 2020 at 8:39 PM Dishant Pandya drpdishant@gmail.com wrote:
Its ok to have something that builds deb packages on Fedora, but in my opinion RPM is far more better then debian packages. Also the Dnf and yum package manager on Fedora are far more advanced than apt on Ubuntu and other Debian Based system. I have been using fedora for over 2 years now and I have never faced the package installation issues that I faced with apt and dpkg, for whatever unknown reasons, may be some corruption of package file, installation state Ubuntu's package manager gets erroneous to an unrecoverable state, and I being a normal desktop user wasn't able to restore the state, and had to reinstall the whole OS from scratch. dpkg/apt is good when it works, but when it breaks its unrecoverable. RPM , dnf/yum are more reliable.
That poor joke of mine keeps hitting home :)
Fedora remains an RPM-based system using DNF. What this change was about was really to allow using apt with deb packages. It makes it easier to pull more tools from the dpkg ecosystem like mock equivalent sbuild.
Nothing to worry about.
Cheers, Dridi
Simply put, "no". Debian and Ubuntu ".deb" packages too often don't follow the File System Hierarchy, they may have different layouts and package naming capitalization schemes for matching Fedora packagers like "PyYAML", they may have overlapping pre-set uids and mismatched group name conventions, etc., etc, and the grub intigration for new kernels is likely to be a nightmare. It would be a full-time job for several competent engineers to do that kind of package impedance matching.
Just..... no.aot abd deb inside a "podman" baswed container? Maybe? But it seems not worth the pain.
Simply put, "no". Debian and Ubuntu ".deb" packages too often don't follow the File System Hierarchy, they may have different layouts and package naming capitalization schemes for matching Fedora packagers like "PyYAML", they may have overlapping pre-set uids and mismatched group name conventions, etc., etc, and the grub intigration for new kernels is likely to be a nightmare. It would be a full-time job for several competent engineers to do that kind of package impedance matching.
I'm not interested in debating Debian and derivatives packaging guidelines, but I generally prefer how Fedora does things (except notably, modularity).
Just..... no.aot abd deb inside a "podman" baswed container? Maybe? But it seems not worth the pain.
The whole point of this change was to allow working with DPKG tooling without leaving the comfort zone of Fedora, without forcing a VM or container indirection. And trust me on this one, I do not inflict Debian packaging on myself by choice so I'm really keen on not adding any needless step, to the point where before submitting this change I had my own homebrew apt package. As a bonus point, this change also retired apt-rpm which had been dead and unmaintained for a decade, and according to the upstream developer himself it had unfixed security issues.
So apt-rpm needed to go anyway, and there was no reason not to replace it with regular apt (apt-rpm would otherwise conflict with apt). And by the way, even though I initiated this change I later lost my ability to implement it, but it's been done since f32 thanks to Neal Gompa and Sérgio Basto.
I hope it clarifies what was actually implemented.
Dridi
On Thu, 2020-07-16 at 10:11 +0000, Dridi Boukelmoune wrote:
Simply put, "no". Debian and Ubuntu ".deb" packages too often don't follow the File System Hierarchy, they may have different layouts and package naming capitalization schemes for matching Fedora packagers like "PyYAML", they may have overlapping pre-set uids and mismatched group name conventions, etc., etc, and the grub intigration for new kernels is likely to be a nightmare. It would be a full-time job for several competent engineers to do that kind of package impedance matching.
I'm not interested in debating Debian and derivatives packaging guidelines, but I generally prefer how Fedora does things (except notably, modularity).
I have to say that, from my perspective due to past experience, having to use the Debian/Ubuntu packaging for development in Fedora would have me scrambling to find another distribution for my desktop.
While dpkg is just a learning curve thing, rpm is much simpler when doing development/bug fixing for me. Indeed the fact that Fedora used rpm is one of reasons I have continued to use Fedora for my desktop for so many years.
Oddly, the subject of the original post infers getting rid of rpm but the post itself sounds like it's proposing something different and that's why I decided to speak up.
Ian
Oddly, the subject of the original post infers getting rid of rpm but the post itself sounds like it's proposing something different and that's why I decided to speak up.
Yes, poor joke of mine, keeps hitting home though :)
Ditching RPM in favor of DPKG was never meant to be a system-wide change, but simply switching Fedora's apt package from apt-rpm to regular apt. The original post was intentionally misleading because I have a particular sense of humor and frankly I didn't think that after months of completion this change would still make my day every once in a while.
https://fedoraproject.org/wiki/Changes/Move_apt_package_from_RPM_to_DPKG_bac...
Seriously, nothing to worry about!
Cheers
On Fri, Jul 17, 2020 at 3:15 AM Dridi Boukelmoune dridi.boukelmoune@gmail.com wrote:
Oddly, the subject of the original post infers getting rid of rpm but the post itself sounds like it's proposing something different and that's why I decided to speak up.
Yes, poor joke of mine, keeps hitting home though :)
Ditching RPM in favor of DPKG was never meant to be a system-wide change, but simply switching Fedora's apt package from apt-rpm to regular apt. The original post was intentionally misleading because I have a particular sense of humor and frankly I didn't think that after months of completion this change would still make my day every once in a while.
Again, "no". It won't work that easy, for exactly the same reasons I already mentioned. The components overlap far too much and will inevitably conflict.
On Thursday, July 16, 2020 3:11:19 AM MST Dridi Boukelmoune wrote:
there was no reason not to replac it with regular apt
Nico touched on these already, but that's simply not possible. Rather, it's possible, but would immediately break your system upon installing software using apt.
On Sat, 18 Jul 2020 at 04:19, John M. Harris Jr johnmh@splentity.com wrote:
On Thursday, July 16, 2020 3:11:19 AM MST Dridi Boukelmoune wrote:
there was no reason not to replac it with regular apt
Nico touched on these already, but that's simply not possible. Rather, it's possible, but would immediately break your system upon installing software using apt.
I believe you and Nico haven't actually touched onto what's actually going on. https://bugzilla.redhat.com/show_bug.cgi?id=apt
https://fedoraproject.org/wiki/Changes/Move_apt_package_from_RPM_to_DPKG_bac...
On Friday, July 17, 2020 10:20:54 PM MST Anthony F McInerney wrote:
On Sat, 18 Jul 2020 at 04:19, John M. Harris Jr johnmh@splentity.com
wrote:
On Thursday, July 16, 2020 3:11:19 AM MST Dridi Boukelmoune wrote:
there was no reason not to replac it with regular apt
Nico touched on these already, but that's simply not possible. Rather, it's possible, but would immediately break your system upon installing software using apt.
I believe you and Nico haven't actually touched onto what's actually going on. https://bugzilla.redhat.com/show_bug.cgi?id=apt
https://fedoraproject.org/wiki/Changes/Move_apt_package_from_RPM_to_DPKG_bac kend
Well aware, but that doesn't solve the problem listed above: As soon as you try to install DPKG software with this, such as from Debian, you will break your system. The two CANNOT be installed to the same rootfs. It's just not going to work. There are too many conflicts.
On Sat, 18 Jul 2020 at 06:29, John M. Harris Jr johnmh@splentity.com wrote:
On Friday, July 17, 2020 10:20:54 PM MST Anthony F McInerney wrote:
On Sat, 18 Jul 2020 at 04:19, John M. Harris Jr johnmh@splentity.com
wrote:
On Thursday, July 16, 2020 3:11:19 AM MST Dridi Boukelmoune wrote:
there was no reason not to replac it with regular apt
Nico touched on these already, but that's simply not possible. Rather, it's possible, but would immediately break your system upon installing
software
using apt.
I believe you and Nico haven't actually touched onto what's actually
going
https://fedoraproject.org/wiki/Changes/Move_apt_package_from_RPM_to_DPKG_bac
kend
Well aware, but that doesn't solve the problem listed above: As soon as you try to install DPKG software with this, such as from Debian, you will break your system. The two CANNOT be installed to the same rootfs. It's just not going to work. There are too many conflicts.
this was about building packages.. https://fedoraproject.org/wiki/Changes/Move_apt_package_from_RPM_to_DPKG_bac...
On Sat, Jul 18, 2020 at 1:21 AM Anthony F McInerney afm404@gmail.com wrote:
On Sat, 18 Jul 2020 at 04:19, John M. Harris Jr johnmh@splentity.com wrote:
On Thursday, July 16, 2020 3:11:19 AM MST Dridi Boukelmoune wrote:
there was no reason not to replac it with regular apt
Nico touched on these already, but that's simply not possible. Rather, it's possible, but would immediately break your system upon installing software using apt.
I responded to what he claimed later was a "joke". It was a bait and switch. The boy is trolling.
On Saturday, 18 July 2020 at 12:19, Nico Kadel-Garcia wrote:
On Sat, Jul 18, 2020 at 1:21 AM Anthony F McInerney afm404@gmail.com wrote:
On Sat, 18 Jul 2020 at 04:19, John M. Harris Jr johnmh@splentity.com wrote:
On Thursday, July 16, 2020 3:11:19 AM MST Dridi Boukelmoune wrote:
there was no reason not to replac it with regular apt
Nico touched on these already, but that's simply not possible. Rather, it's possible, but would immediately break your system upon installing software using apt.
I responded to what he claimed later was a "joke". It was a bait and switch. The boy is trolling.
Oh, come on. Are you serious? This was an actual implemented change to switch Fedora apt package from apt-rpm, which was dead upstream to the Debian apt to make building of Debian packages on Fedora easier. No trolling. The only joke was in the subject and it seems people are still falling for it. Please just stop putting your foot in it[1].
[1] Strange idiom, that one.
Regards, Dominik
Yeah, let's please just stop this thread? I can't see anything further productive coming out of it. Thank you.
Its ok to have something that builds deb packages on Fedora, but in my opinion RPM is far more better then debian packages. Also the Dnf and yum package manager on Fedora are far more advanced than apt on Ubuntu and other Debian Based system. I have been using fedora for over 2 years now and I have never faced the package installation issues that I faced with apt and dpkg, for whatever unknown reasons, may be some corruption of package file, installation state Ubuntu's package manager gets erroneous to an unrecoverable state, and I being a normal desktop user wasn't able to restore the state, and had to reinstall the whole OS from scratch. dpkg/apt is good when it works, but when it breaks its unrecoverable. RPM , dnf/yum are more reliable.
devel@lists.stg.fedoraproject.org
-
Akarshan Biswas -
Anthony F McInerney -
Dishant Pandya -
Dominik 'Rathann' Mierzejewski -
Dridi Boukelmoune -
Emmanuel Seyman -
Graham Leggett -
Ian Kent -
Japheth Cleaver -
John M. Harris Jr -
Leigh Scott -
Matthew Miller -
Neal Gompa -
Nico Kadel-Garcia -
Panu Matilainen -
Sérgio Basto -
Tomasz Kłoczko