3 ms·

I've made, in the distant past, into the triple digits of RPMs. I actually really liked making RPMs: just a single .srpm file that included the instructions an

I've made, in the distant past, into the triple digits of RPMs. I actually really liked making RPMs: just a single .srpm file that included the instructions and postinstalls and the like. Fairly straightforward to produce. I've also built in the double digits deb files, and I've always loathed the task. Even just starting from an existing deb src and trying to adapt it to my new package was always painful and as often as not I'd dig through the documentation and end up having to "phone a friend" for help. I'd get a magic incantation that would work, but I'd never quite internalize why or how I was supposed to know that. I know there are tons of people who produce deb packages, so this is clearly a "me" problem, but as much as I wish I could contribute to the debian packaging world, it has just been impenetrable for me. Kind of theraputic to hear others here saying similar.

thayne 3y ago
It's not just you. I've never packaged RPMs, but I have made archlinux packages, which are incredibly simple, you just write a bash script with certain conventions. But the process for building debs seems unnecessarily complicated to me. There are a bunch of different tools you need to use, several steps, multiple files you need to create, etc. And finding good documentation is difficult.
- deleted 3y ago
  [deleted]
- anthk 3y ago
  Hyperbola user here. PKGBUILD's are really easy, second on easiness on Slackware's Slackbuilds which were pretty close, but Slackware predates Arch by a decade and a half.
js2 3y ago
On the consumer side, I prefer rpm/yum/dnf to deb/dpkg/apt. The later just really seems more like a collection of loose parts. I was surprised the other day that dpkg has no equivalent to rpm's `--last` switch to find when a particular package was installed. At best you can recover this information from the dpkg log (if it hasn't rotated out of existence) and/or modification times of the files under `/var/lib/dpkg/info/` if they've never been touched by accident.
perlgeek 3y ago
It took me quite a while to actually understand how Debian packaging works; I haven't really found any good, approachable documentation that explains the concept behind it. Once I thought I understood it, I've tried to write it down myself, in book form. In case it helps, you can get it here for free for a while: https://leanpub.com/debian/c/hn-2024-01 https://leanpub.com/debian/c/hn-2024-01 But to be honest, even though I think I have a pretty good grasp how it works overall, I still sometimes run into hard-to-debug problems, or I think I know which hook to use, but it still doesn't work, inexplicably. dh is very flexible, to the point of sometimes being maybe too flexible to fully understand.
ok123456 3y ago
Does your use case fall outside of the scope of checkinstall? If you have a build system that has or generates an install target and doesn't require anything fancy, I've found that that saved me from learning that much about Debian packaging.

thayne 3y ago

It's not just you. I've never packaged RPMs, but I have made archlinux packages, which are incredibly simple, you just write a bash script with certain conventions. But the process for building debs seems unnecessarily complicated to me. There are a bunch of different tools you need to use, several steps, multiple files you need to create, etc. And finding good documentation is difficult.

deleted 3y ago
[deleted]
anthk 3y ago
Hyperbola user here. PKGBUILD's are really easy, second on easiness on Slackware's Slackbuilds which were pretty close, but Slackware predates Arch by a decade and a half.

js2 3y ago

On the consumer side, I prefer rpm/yum/dnf to deb/dpkg/apt. The later just really seems more like a collection of loose parts. I was surprised the other day that dpkg has no equivalent to rpm's `--last` switch to find when a particular package was installed. At best you can recover this information from the dpkg log (if it hasn't rotated out of existence) and/or modification times of the files under `/var/lib/dpkg/info/` if they've never been touched by accident.

perlgeek 3y ago

It took me quite a while to actually understand how Debian packaging works; I haven't really found any good, approachable documentation that explains the concept behind it. Once I thought I understood it, I've tried to write it down myself, in book form. In case it helps, you can get it here for free for a while: https://leanpub.com/debian/c/hn-2024-01 https://leanpub.com/debian/c/hn-2024-01 But to be honest, even though I think I have a pretty good grasp how it works overall, I still sometimes run into hard-to-debug problems, or I think I know which hook to use, but it still doesn't work, inexplicably. dh is very flexible, to the point of sometimes being maybe too flexible to fully understand.

ok123456 3y ago

Does your use case fall outside of the scope of checkinstall? If you have a build system that has or generates an install target and doesn't require anything fancy, I've found that that saved me from learning that much about Debian packaging.