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.
