I wish the author's complaints about RPMs would be taken seriously. I'm a pretty experienced dev and sysadmin, a packaging a simple CLI app written in C with an easy compile process (and no dependencies other than glibc) was a giant pain in the ass, and in the end I doubt I did it the "right" way despite hours and hours of effort to do so, as I made use of docker to get builds for various active Fedora versions and RHEL versions without having to provision a complete system with each.
I don't know if it's documentation or the RPM tools/macros that suck, or some combination of both, but it's a real setback for someone trying to contribute packages. Getting a contribution into the Fedora repos was also a giant pain in the ass, as there is process there but the documentation is entirely unclear what that process is unless you already know what the process is.
My opinion of the RPM macro system is that I can see why it was done that way, and it was an admirable approach to make packages easy to read, but there's way too much magic. I'd rather parse a couple lines of shell script that made it clear what was happening, than have to look through a handful of macros that aren't documented well (or good documentation is impossible to find). Arch's PKGBUILD format is amazing, and I'd love to see it used as inspiration for an RPM replacement (or at least alternative approach). I try to be very wary of the "the last developer sucked" fallacy when coming into a new and unfamiliar project, but there are enough similar experiences to mine that I think this criticism is valid.
That said, much appreciation and love for the dedicated people who maintain and build RPMs for us. It's often thankless work, but without it we would have nothing.
The issue is that mock does nothing for moving sources in place, it's just rpmbuild and a chroot. From what I could figure out, fedpkg is more about working with existing Fedora packages shipped as part of the official repositories, and less about "Here's how to get this random project you don't own into copr".
This assumes there's an RPM spec file in your working directory and proper handling of sources within/nearby. Fedpkg will create a 'results' directory with the SRPM and RPMs
The -r $mock_root part can be repeated if you want to build against multiple targets in COPR
My experience with RPM is fairly limited, but I have a similar experience with Debian's .deb format. My rough understanding is deb is not as complicated as rpm, but I still have yet to succeed at packaging something with either. Meanwhile I've had a much easier time with APK and PKGBUILD from Alpine and Arch respectively. Why is it these packaging systems make it so much easier while the juggernauts of the Linux distro world have such complicated, poorly documented messes?
> Why is it [APK and PKGBUILD] make it so much easier while the juggernauts of the Linux distro world have such complicated, poorly documented messes?
If I had to venture a guess, I'd point to 3 factors:
1. They're both much younger than their 'juggernaut' counterparts.
2. They both have explicit commitments to simplicity, perhaps even at the cost of other virtues should push come to shove.
3. The documentation exists primarily to facilitate the maintenance of the distro itself, which is done sustained by inducting members into a community and documents are referred to users in a process of inculcation.
Documents that work well enough for (3) may not be that helpful to someone who expects to be able to sit down by themselves and slap together a package to maintain for their own usage or to submit as a drive-by contribution.
In the Arch world, at least, drive-by contributions play a crucial and esteemed role in the ecosystem, namely in the AUR. Perhaps similar is true in Alpine, as well.
I have had a similar experience packaging a simple python program, coming from zero packaging experience. PKGBUILD was the first I did and by far the easiest, deb was about 3x more time and effort, and rpm was a bit more time and effort still, despite now having experience with the other two. I wanted to package for nix next, but got stuck due to the program daemonizing and can no longer import its dependencies.
It's picosnitch, if you know what I'm doing wrong/how to fix it that'd be great! It depends on bcc and psutil, and I am able to build and run it from a .nix file using python3.pkgs.fetchPypi with
However, when I run it with just start, it can no longer find psutil and bcc. It uses a daemon class here [1].
I also encounter the same issue when running it without sudo, since it will re-execute itself here [2].
It can also use systemd, but I didn't get around to figuring out how to use systemd and install the service file on nix (I've never used nix before and know very little).
All nix packages are self-contained ("portable" in Windows parlance), programs don't get a default working PATH. You need to craft PATH yourself, usually using wrapProgram.
If you run into new issues with the package in trying to leverage wrapProgram, feel free to open a thread on discourse.nixos.org and also to @ me there!
Picosnitch seems like a nifty utility and it's awesome that you've taken up that packaging effort to make your work more available for users of so many distros. :)
I've lots of experience with both. Debian, while not perfect, is miles better than the rpm systems. Both require knowledge, because thinking of all the multitudes of edge cases makes things complicated. Don't have personal experience with Alpine or Arch, but I suspect they're not as general. Nobody WANTS to create lots of complexity for no reason.
> Nobody WANTS to create lots of complexity for no reason.
Agreed. I think in the case of RPMs and Debs, it evolved to this point. I would guess the first versions of RPM and the macros were amazingly easy to package, probably much better than PKGBUILD is now.
The problem happened that software started getting written in tons of different languages rather than usually in C, with different libraries/dependencies, different strategies and edge cases, and the system kept expanding to accomodate. Eventually it's a mess because there are too many macros, it's now too magical, and documentation hasn't been made a high priority because it's a relatively small group that uses it, and they don't need the docs. Once you know it too, there's not a lot of reason to change it and even more reason not to change it (cause that's a ton of work for little to no gain among the majority of the maintainers). I don't mean this as a criticism, just a pattern I've seen over and over having worked on software for a long time.
I think the actual package format for RPM probably doesn't need to change too much, it's the tooling and docs that do. I'd love to see a new project that is compatible with the RPM format but uses a system more like PKGBUILD.
rpm is heinous. They need to handle comments and then expand macros so that you can comment-out stuff in your .spec without getting mystery errors from multi-line macros. If they can't even get this right after decades, they're hopeless.
I have rolled my own RPMs for OpenSUSE TW. I learned about the build process from a site aimed at Fedora and got the syntax right(ish) by looking at a bunch of official .SPECs from the OpenSUSE project. I also looked at packaging .debs, but that looks like an utter pain.
This matches my impression and experience, and I've been surprised to see many commenters here write that they found DEB packages to be simpler to write.
Perhaps as openSUSE users we both found the whole process easier because openSUSE drew us to OBS, and that made actually building the package easier?
RPM is much simpler than .deb, so guide is not necessary. It's just a simple .spec file with few headers and sections. See src.fedoraproject.org[0] for Fedora .spec files (click or search a package, then click on Files tab, then .spec file).
However, Fedora uses "convention over configuration" principle, so a packager must know Fedora conventions to package a program properly.
I find the Debian maintainer guide helpful enough! To me the difficulty difference is not large, but I like the simplicity of managing just a single spec file for RPM source packages.
I think the problem is greater than RPM vs DEB vs ... It goes all the way back to the Linux philosophy "let the user break things".
I think some people use Linux to avoid paying Windows license fees or Apple's premium. There are tools only developed for Linux, but the opposite is also true for Windows and macOS. I've found most macOS apps follow Apple's core philosophy to be simple, aesthetically appealing, and easy to use. Can't say that for Linux packages (and to some extent, even Windows apps suck).
I view Linux mostly as an environment where you're free to do whatever you want, even shoot yourself in the foot. But I'd never recommend that to average Joe, for reasons such as the fact that this article exists.
Nobody uses Linux to avoid paying Windows because Windows comes preinstalled on most computers and because Windows piracy exists and is tolerated by Microsoft in order to entrench Windows usage. Switching to Linux is a deliberate choice to prefer the benefits only Linux offers and/or to avoid the detriments of all other options. The majority use the preinstalled default: Windows.
Also nobody uses Linux to avoid Apple's premium because macOS is free. A minority of people install Linux on Macs because they prefer/need Linux even if they already paid the Apple premium. The rest simply use the preinstalled default: macOS.
For a user with basic needs and no dependency on some Windows-only software, Linux is a viable choice.
Was there ever a time when "Unix" apps primarily targeted macOS? Because in most cases I've encountered, apps are only tested on Linux and macOS compatibility is an afterthought.
If it was a Linux problem (which is an interesting thing to think about), wouldn't you expect to see the same issues in all the distros? Arch, Alpine, etc seem to have a pretty good system. PKGBUILD in particular I found great.
>packaging a simple CLI app written in C with an easy compile process (and no dependencies other than glibc) was a giant pain in the ass
That's why i love to work with FreeBSD-ports and pkgsrc from netbsd, it's just so easy and the community helps you quite allot if your are in a corner-(case).
I don't know if it's documentation or the RPM tools/macros that suck, or some combination of both, but it's a real setback for someone trying to contribute packages. Getting a contribution into the Fedora repos was also a giant pain in the ass, as there is process there but the documentation is entirely unclear what that process is unless you already know what the process is.
My opinion of the RPM macro system is that I can see why it was done that way, and it was an admirable approach to make packages easy to read, but there's way too much magic. I'd rather parse a couple lines of shell script that made it clear what was happening, than have to look through a handful of macros that aren't documented well (or good documentation is impossible to find). Arch's PKGBUILD format is amazing, and I'd love to see it used as inspiration for an RPM replacement (or at least alternative approach). I try to be very wary of the "the last developer sucked" fallacy when coming into a new and unfamiliar project, but there are enough similar experiences to mine that I think this criticism is valid.
That said, much appreciation and love for the dedicated people who maintain and build RPMs for us. It's often thankless work, but without it we would have nothing.