Would be an awesome tool guide to see a workflowchart of Debian tools.
The naming of tools often gets lost in the way things are built.
I do not know if the centralized approach of using "rpmbuild" (via command line options" is better for workflow or debian multi-tools (via separate executable) is better UNIX approach.
But at any rate, a workflowchart would be "awesome" of Debian.
Glad there is better tooling, but in 5 years, when I'll need it, I'm pretty sure I won't know how to use it.
I've had to build a deb package once. It's crazy how few docs and resources there are to do so, and how of poor quality they are.
The package format itself is quite complex, and you don't know if you must do something imperatively or decoratively, when to trigger it in the workflow of the install, if it makes sense to use debconf or not, how to use debconf with something else than bash, good practices, where to put things, to copy files, etc. And that's before you have to deal with dependencies.
Then you have to repeat that for rpm.
No wonder people are attracted to flatpak and snap.
Creating a installer for mac, windows and linux is a hell of a work. Not to mention making sure it compiles and run on all those platforms.
Maybe you want a non deb specific packager. cpack (cmake packager) can generate Windows, OSX, DEB, RPM and simple archives. There is also fpm that doesn't support Windows, but supports plenty of packet managers. And possibly many others.
AppImage, FlatPak and Snap may actually be worse in that regard, because they are like other distros you have to take into account. So now, you may have to do all of them: deb, rpm, flatpak, snap, appimage, tgz, whatever that's on Windows and OSX, maybe a Docker container too, app stores and mobile stuff, and upload to some npm, maven, crate.io,... It makes generic package manager even more important.
The dh tools have a lot of magic to them. Arguably it works rather well, but figuring out how exactly to build a package correctly is difficult. The documentation is pretty bad, so if you want to do anything slightly different than the standard, your going spelunking in the debian directory of existing packages.
Debian could fix a lot of the troubles with the existing Debian Helper tools by improving the documentation.
For me rpm was relatively easy to grasp, it's basically a shell script and each section has a specific job (building, preparing, copying files etc.)
No matter how much I tried I could never grasp deb packaging. The documentation is very sparse and the debhelper commands seem like magic. I couldn't find out what all the different files like .dirs or .install did, so I just gave up.
I find RPM specs to be pretty frustrating. Easy cases like packaging GNU Hello is fine, but things get out of control really fast once you fall off the happy path. RPM specs are based simple text substitution. It lacks the flexibility to make adjustments to the build, the power to build good abstractions, and comes with all the same drawbacks of the C preprocessor. On top of that, documentation is lacking for basic macros, language ecosystem support is spotty and scattered across various obscure projects, and SCL packaging is a complete nightmare. The whole design seems dated compared to other solutions.
At that point, why even use package managers? That approach won't benefit from existing packaging infrastructure at all. Might as well distribute binaries in tarballs instead for simplicity.
https://nixos.org/download#download-nix <--- I'm bookmarking this cause I keep forgetting that Nix can run atop other systems. I have no excuse to not give it a try
The easiest package format I've ever came across was the tgz format from Slackware. From what I remember, you just build and install your software in a fake root then tar gzip it up.
This is because it doesn't do very much. Arch Linux's PKGBUILD and Alpine's APKBUILD are an excellent improvement on that, still very simple to use and learn. In most cases the source package consists of a single shell script (unlike Debian's splintered hell) where you have to define half a dozen fields and a couple of functions (build && install).
I basically have to relearn Debian packaging from scratch every time I have to do that, but learn Alpine and/or Arch once and you're all set.
It's the same process for all package builders: install build-time dependencies, unpack source archive with a program, configure it, build it, install it to a fake root, validate it, archive it to the package, sign it, then publish it to a repository, update repository index.
Binary deb packages are extremely simple. It's just a cpio archive with a couple of tarballs & almost every system integration is implicit. Very easy to build by hand.
Last time I shipped a debian package to clients we just had the build system spit out a ready made binary .deb. Much, much easier than faffing about with dhbuild etc.
My work workflow use `dpkg-deb`: I just create a "build/DEBIAN" directory, populate it with the control file and any post/pre scripts I need, put everything else in the "build" directory where it goes on the end filesystem and then do "dpkg-deb build ." I put all this into a script and do "fakeroot <SCRIPTNAME>".
I usually start with the `dh_make` generated skeleton and incrementally add overrides as I iterate with `gbp buildpackage`. It's not pretty, but it's what I know.
> I've had to build a deb package once. It's crazy how few docs and resources there are to do so, and how of poor quality they are.
After doing the first one, I was able to build binary, Debian packages in 5 minutes tops, while chatting with a friend during the process, too.
flatpak and snap are designed to solve different problems than OS native packaging paradigms.
Also, .deb and .rpm are much more capable and sophisticated than they look on the surface. Lastly, extracting a source and binary Debian package provides great documentation in itself.
Lastly, use lintian. That thing is a godsend (and does binary static analysis, too!).
I have both hated and appreciated debian packaging, largely depending on the thing I was trying to package at the time. Things implemented in C/C++ and built with vanilla cmake are feasible. Other things get complicated very quickly.
If you're willing to absorb that complication, then debhelper really will handle any and every situation. It is a hell of an investment, though.
In the distant past I did a small amount of packaging both formats. We're talking 10-20 years ago (the past decade I'm only deb packages, but I "cheat" as described elsewhere, using "dpkg-deb"). I wouldn't say "deb" is inferior, but I would say it's much harder. I actively enjoyed creating SRPMs, but never got past loathing building deb srcs. I've had friends who loved debs, or at least could create them in their sleep, but I never got anywhere near there.
I don't think it's fair to expect third-party developers to keep track of all this and produce fully compliant packages without resorting to hacks like fpm. I have a couple of staging servers running Alpine and am thinking of switching more serious workloads to it. Maybe switching fully some day if that works out fine. I was surprised how easy it is to write Alpine packages, they don't change formats every week so your knowledge stays current, and I wrap even basic shell scripts in packages now. Not something I ever did for Debian systems.
In other words, in 16 years of dh being a thing it still hasn't acquired decent documentation, and how you're pushing another solution which is going to be undocumented for another 16-18 years. It's not just "my" rant, look at comments in every Debian packaging thread, this one included. The opposite is the exception.
If we can push Ubuntu out of the pole position, then I think we can solidify Alpine as the next great Linux distribution. I am all for simpler packaging.
I do fear, though, that Debian packaging has absorbed some necessary complexity that Alpine packaging has not --- if only because Debian has been around so much longer.
Arch has a very similar package format and is 21 years old. Alpine is more than 18. They haven't accrued much cruft in that time. One could argue they have worse support for things like cross-compilation, but many (most?) of us don't need that, and I see no reason to pay for it in 99% of use cases.
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.
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.
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.
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.
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
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.
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.
50 comments
[ 2.9 ms ] story [ 113 ms ] threadThe naming of tools often gets lost in the way things are built.
I do not know if the centralized approach of using "rpmbuild" (via command line options" is better for workflow or debian multi-tools (via separate executable) is better UNIX approach.
But at any rate, a workflowchart would be "awesome" of Debian.
https://wiki.debian.org/Wajig https://github.com/gjwgit/wajig
I've had to build a deb package once. It's crazy how few docs and resources there are to do so, and how of poor quality they are.
The package format itself is quite complex, and you don't know if you must do something imperatively or decoratively, when to trigger it in the workflow of the install, if it makes sense to use debconf or not, how to use debconf with something else than bash, good practices, where to put things, to copy files, etc. And that's before you have to deal with dependencies.
Then you have to repeat that for rpm.
No wonder people are attracted to flatpak and snap.
Creating a installer for mac, windows and linux is a hell of a work. Not to mention making sure it compiles and run on all those platforms.
Sometimes more than coding the program itself.
AppImage, FlatPak and Snap may actually be worse in that regard, because they are like other distros you have to take into account. So now, you may have to do all of them: deb, rpm, flatpak, snap, appimage, tgz, whatever that's on Windows and OSX, maybe a Docker container too, app stores and mobile stuff, and upload to some npm, maven, crate.io,... It makes generic package manager even more important.
Debian could fix a lot of the troubles with the existing Debian Helper tools by improving the documentation.
No matter how much I tried I could never grasp deb packaging. The documentation is very sparse and the debhelper commands seem like magic. I couldn't find out what all the different files like .dirs or .install did, so I just gave up.
And nix.
> Creating a installer for mac, windows and linux is a hell of a work
Nix gets you mac, linux and WSL support.
https://nixos.org/download#download-nix <--- I'm bookmarking this cause I keep forgetting that Nix can run atop other systems. I have no excuse to not give it a try
1: https://github.com/DeterminateSystems/nix-installer?tab=read...
I basically have to relearn Debian packaging from scratch every time I have to do that, but learn Alpine and/or Arch once and you're all set.
https://gitlab.archlinux.org/archlinux/packaging/packages/mu...
https://git.alpinelinux.org/aports/tree/community/mutt/APKBU...
Last time I shipped a debian package to clients we just had the build system spit out a ready made binary .deb. Much, much easier than faffing about with dhbuild etc.
After doing the first one, I was able to build binary, Debian packages in 5 minutes tops, while chatting with a friend during the process, too.
flatpak and snap are designed to solve different problems than OS native packaging paradigms.
Also, .deb and .rpm are much more capable and sophisticated than they look on the surface. Lastly, extracting a source and binary Debian package provides great documentation in itself.
Lastly, use lintian. That thing is a godsend (and does binary static analysis, too!).
If you're willing to absorb that complication, then debhelper really will handle any and every situation. It is a hell of an investment, though.
https://trends.debian.net
I don't think it's fair to expect third-party developers to keep track of all this and produce fully compliant packages without resorting to hacks like fpm. I have a couple of staging servers running Alpine and am thinking of switching more serious workloads to it. Maybe switching fully some day if that works out fine. I was surprised how easy it is to write Alpine packages, they don't change formats every week so your knowledge stays current, and I wrap even basic shell scripts in packages now. Not something I ever did for Debian systems.
Have a look at official packages for an example:
https://git.alpinelinux.org/aports/tree/main?h=3.12-stable
https://git.alpinelinux.org/aports/tree/community?h=3.12-sta...
- dh: 2008-present
Building something on top of dh at this point, like dh was built on debhelper, does not seem to justify your rant. But what do I know?
I do fear, though, that Debian packaging has absorbed some necessary complexity that Alpine packaging has not --- if only because Debian has been around so much longer.
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.
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.
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
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.