3 ms·

https://salsa.debian.org/python-team/packages/todoman/-/blob/master/debian/control https://salsa.debian.org/python-team/packages/todoman/-/blob... https://sals

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.

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.