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.
nix-build -E 'with import <nixpkgs> {}; callPackage ./picosnitch.nix {}'
sudo -E ./result/bin/picosnitch start-no-daemon
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).
[1] https://github.com/elesiuta/picosnitch/blob/master/picosnitc...
[2] https://github.com/elesiuta/picosnitch/blob/master/picosnitc...
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. :)
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.