3 ms·

> sometimes you get lucky and the packaging instructions are easy to write (Debian rules, RPM specfiles, whatever Arch uses, etc) Funny way to word this. Arch

> sometimes you get lucky and the packaging instructions are easy to write (Debian rules, RPM specfiles, whatever Arch uses, etc) Funny way to word this. Arch’s PKGBUILD syntax is very very simple. If you now some programming (especially some shell scripting), you should be able to figure out all the basics. Here’s a non-trivial example: https://gitlab.archlinux.org/archlinux/packaging/packages/todoman/-/blob/main/PKGBUILD https://gitlab.archlinux.org/archlinux/packaging/packages/to... Alpine’s APKBUILD are pretty similar too. Here’s the same package as above: https://git.alpinelinux.org/aports/tree/testing/todoman/APKBUILD https://git.alpinelinux.org/aports/tree/testing/todoman/APKB... Debian packages? Good luck trying to write one. Fedora’s specfiles are far from simple too… though you might be able to at least read one and get a vague idea of what’s going on. I suspect both of these two are the way they are due to historical reasons… it’s a shame that they’re unlikely to change. There’s so much simpler way to write packages.

mike_hock 3y ago
https://salsa.debian.org/python-team/packages/todoman/-/blob/master/debian/control https://salsa.debian.org/python-team/packages/todoman/-/blob... https://salsa.debian.org/python-team/packages/todoman/-/blob/master/debian/rules https://salsa.debian.org/python-team/packages/todoman/-/blob... https://salsa.debian.org/python-team/packages/todoman/-/blob/master/debian/todoman.install https://salsa.debian.org/python-team/packages/todoman/-/blob... If you concatenate them, you get about the same as the PKGBUILD and APKBUILD files. There's a couple more one-liners that I omitted. I fail to see how one is supposed to be easy and the other is hard.
- mkj 3y ago
  The debian ones seem to have more bespoke languages to learn rather than shell script fragments, and more mystery dh-* things that need to be known.
  - mike_hock 3y ago
    That is true, but it's not "good luck making one." The "bespoke language" of debian/control is trivial, debian/rules is a makefile and the rest is mostly "one file glob per line" or that sort of thing.
  - rubicks 3y ago
    Ah, yes. Debhelper, and its many integrations. I routinely work with the various attachments dedicated to the management of sysuser accounts, systemd units, config files... Yes, it's daunting. It also handles literally everything.
- WhyNotHugo 3y ago
  I can copy the commands from the PKGBUILD or APKBUILD and run them on a shell to replicate the same work. I can also pick up a random PKGBUILD and modify it to install some completely different package (this is how many people learn these packaging formats). Looking at those three links that you provided for a Debian package, and I don't see a single clue as to how the package is built, nor how to adapt that to build something else. I'm sure there's a manual somewhere, but that's the point: PKGBUILD and APKBUILD files are far easier to understand by just looking at them (assuming the reader knows some shell scripting). I actually just glanced through the whole documentation for the "control" file (btw: what does "control" even mean in this context?): https://www.debian.org/doc/debian-policy/ch-controlfields.html https://www.debian.org/doc/debian-policy/ch-controlfields.ht.... Still no idea on how this builds todoman. I'll also point out that I'm the maintained of todoman upstream -- so I _know_ how to build this software, but I don't see any clues as to how the debian package builds it. I hope this makes it a bit clearer why one packaging definition is considered simple and the other hard.
forgotpwd16 3y ago
>Fedora’s specfiles are far from simple too This is arguable. For example for the same project: https://copr-dist-git.fedorainfracloud.org/cgit/watchdog/todoman/todoman.git/tree/todoman.spec https://copr-dist-git.fedorainfracloud.org/cgit/watchdog/tod... If know what `%py_build`, `%py3_install`, etc are and do then is much simpler to write, read, and manage. There's a standardized way that all python packages can be made rather copy-pasting instructions around. Of course there's the hidden complexity those commands bring on what they're doing behind the scenes.

mike_hock 3y ago

https://salsa.debian.org/python-team/packages/todoman/-/blob/master/debian/control https://salsa.debian.org/python-team/packages/todoman/-/blob... https://salsa.debian.org/python-team/packages/todoman/-/blob/master/debian/rules https://salsa.debian.org/python-team/packages/todoman/-/blob... https://salsa.debian.org/python-team/packages/todoman/-/blob/master/debian/todoman.install https://salsa.debian.org/python-team/packages/todoman/-/blob... If you concatenate them, you get about the same as the PKGBUILD and APKBUILD files. There's a couple more one-liners that I omitted. I fail to see how one is supposed to be easy and the other is hard.

mkj 3y ago
The debian ones seem to have more bespoke languages to learn rather than shell script fragments, and more mystery dh-* things that need to be known.
- mike_hock 3y ago
  That is true, but it's not "good luck making one." The "bespoke language" of debian/control is trivial, debian/rules is a makefile and the rest is mostly "one file glob per line" or that sort of thing.
- rubicks 3y ago
  Ah, yes. Debhelper, and its many integrations. I routinely work with the various attachments dedicated to the management of sysuser accounts, systemd units, config files... Yes, it's daunting. It also handles literally everything.
WhyNotHugo 3y ago
I can copy the commands from the PKGBUILD or APKBUILD and run them on a shell to replicate the same work. I can also pick up a random PKGBUILD and modify it to install some completely different package (this is how many people learn these packaging formats). Looking at those three links that you provided for a Debian package, and I don't see a single clue as to how the package is built, nor how to adapt that to build something else. I'm sure there's a manual somewhere, but that's the point: PKGBUILD and APKBUILD files are far easier to understand by just looking at them (assuming the reader knows some shell scripting). I actually just glanced through the whole documentation for the "control" file (btw: what does "control" even mean in this context?): https://www.debian.org/doc/debian-policy/ch-controlfields.html https://www.debian.org/doc/debian-policy/ch-controlfields.ht.... Still no idea on how this builds todoman. I'll also point out that I'm the maintained of todoman upstream -- so I _know_ how to build this software, but I don't see any clues as to how the debian package builds it. I hope this makes it a bit clearer why one packaging definition is considered simple and the other hard.

forgotpwd16 3y ago

>Fedora’s specfiles are far from simple too This is arguable. For example for the same project: https://copr-dist-git.fedorainfracloud.org/cgit/watchdog/todoman/todoman.git/tree/todoman.spec https://copr-dist-git.fedorainfracloud.org/cgit/watchdog/tod... If know what `%py_build`, `%py3_install`, etc are and do then is much simpler to write, read, and manage. There's a standardized way that all python packages can be made rather copy-pasting instructions around. Of course there's the hidden complexity those commands bring on what they're doing behind the scenes.