Have you built a .deb with debuild and debhelpers? Can you recall all the goofy rules about what needs to go in each file and what each debhelper does? How do you keep all of it in version control and build downstream packages that depend on the changed one? Have you managed to accidently sneak a local build machine dependency or piece of information by accident into the final .deb only to realize it much later?
I found it be a big ball of easily forgettable twine of rules tools and oddities myself that every time I needed to redo something was a hassle. With many foot guns that lead to odd package issues.
debhelper is a library of tools for building packages. Debian users should not need to be aware debhelper exists, or even have it installed.
Maybe you meant debconf? When I was a DD it was an RC bug if your package used debconf to do "magic", i.e. using it as a registry for an application, or not properly re-seeding answers from the configuration and assuming the debconf db was the source of truth.
Meh, from a source point of view, once I have a debian/ directory, with a properly set up rules file, building becomes trivial. Then it is matter of generating a package per-distro/version with the right environment. This could be very well done in an automated manner and a few vms.
The admins and distribution maintainers in this article are really a proxy for all stakeholders beyond a developer who's doing the minimum to get a feature into production.
But, the requirements the tooling and workflows were built for didn't lend themselves to use in development, preventing evolution into tools that work well for more use cases.
I started rebuilding and deploying .debs with custom patches for production 15 years ago. For some projects .rpms or .debs are the only way we distribute builds that go beyond individual developer workstations. It's an absolute luxury on projects that are amenable to workflow. But I've never been a distro maintainer. So I both feel limitations of the tool, and simultaneously don't feel like I have a good grasp on leveraging those those tools as well as I could.
Debian packaging lacks a practical guide that is comprehensive enough to cover all modern use cases, but at the same time doesn't lack focus and goes to the point. The official docs are very extensive, but then they lack self-references to guide the reader to the interesting parts, or surprisingly lacks information that one would expect to find in there.
You will read about debian/rules file, but then open one from any example project and only see a single rule calling "dh". Turns out debhelper is there doing things for you. On to read about debhelper. But now sometimes you'll see some rules file that uses the target "override_dh_autoreconf", which was not explained, not even hinted, in the previous docs. On to read more.
Did you think you got everything? Not so fast!
You'll document yourself about debian/control files and see that using some variable-like names are common in lots of projects. For example this is used a lot:
Depends: ${misc:Depends}, ${shlibs:Depends}
On with the same issue. For some reason (which new users reading the docs shouldn't really have to care), "shlibs:Depends" seems to be used all over the place, but it is not mentioned, hinted, or even suggested in a mere "see also" paragraph in the docs about debian/control. If you are thorough enough you'll end up seeing a quick mention in a different section (8. Shared Libraries), and turns out the actual definition of this variable has to be checked out from "dpkg-shlibdeps", an independent package.
Now how to actually build a package?
In the old days, the debian/rules file contained all the steps, but all is now helpfully abstracted by simply calling debhelper (dh). But calling debian/rules itself is abstracted also by dpkg-buildpackage. Calling dpkg-buildpackage is itself covered by debuild. And debuild is possibly covered by calling git-buildpackage. There is a crazy pile of tools calling tools calling other tools, that is nothing but extremely confusing for newcomers.
For the 99% of times you just want a local package for local installation, dpkg-buildpackage is what you want. But getting to that conclusion is not something you get pointed to from a brief introduction from an official manual. You get to that conclusion after either studying all tools and putting order to all scattered knowledge in your head, or after blindly following some random blog of forum post (which tend to be correct because thankfully all this tooling doesn't change much over time)
EDIT to stress that all information is there, but the official docs lack a good enough effort of linking or including everything in such a way that it follows a logical learning process for newcomers.
You only even need to go the debhelper route if you're intending your package to go upstream into Debian or Ubuntu itself. You can go a looooong way with just `DEBIAN/control` and `dpkg-deb --build`.
This is my biggest gripe with debian packaging. Also, the use of make files and the magic that goes on behind the scenes with debhelper (which you probably want to use) makes packaging much less transparent.
It took me days to grok how to make a proper debian package nearly a decade ago when I first did it - writing my first .spec file took an hour or so and now I can hammer most of them out in 15 minutes or less.
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.
Sure, but building debian packages is akin to needing to read lord of the rings before doing anything. There's so many deb helpers and various files/file formats that need to be understood. How and where files should go. It's horrendously complex compared to PKGBUILD and makepkg.
I totally agree. I'm amazed by how opaque and difficult to understand the process to create debian packages is because of all the various layers/helpers/tools that can/should be used in different cases and the difficulty in customizing things. There's a slew of interacting tooling (`dpkg`,`dpkg-buildpackage`, `debhelper`, each of the debhelper `dh-*` helpers, `sbuild`, `pbuilder`, `git-buildpackage`) that all has different documentation of varying quality, some of it replaces other pieces, etc.
My best experiences with packaging on linux have been gentoo ebuilds & arch pkgbuilds. These keep the build model pretty straight forward if the goal is to "just build a package".
That said: creating a dpkg is not an impossible thing to do. It's just more painful than it needs to be
Debian-based distros make it easy to rebuild .deb's with extra patches. Source package management and build-time dependency tracking is integrated in the package manager, so it's just a matter of downloading the source, adding your own .patch file and rebuilding.
Whenever I've wanted to package .deb's I've just blatantly ignored the official way, and opted for a much simplified setup (write the control file and the pre/post-int scripts, and use a Makefile to build the filesystem hierarchy required and run the appropriate tools).
I agree, though, as much as the RPM spec files are horrible, it's still overall simpler.
I have the exact oposite experience. Building/packaging/maintainig my own software with RPMs is pretty straight foreward, whilst packaging the same software as .deb is a rollercoaster which often goes off track and down a deep hole.
* creating Debian packages is a difficult process to learn. There’s a bunch of tools and wrappers around those tools to handle inadequacies and it’s not clear how to do it “right”. For example, if I just have a binary and want to put it into a Debian package without pulling in some random shell scripts that aren’t part of Debian proper, it’s not immediately clear how to do that.
* Non-atomic and imperative install/remove/etc. hooks make it difficult to robustly handle failures. Since there is no file system manifest or sandboxing, there’s no real guarantees that removing a package will actually remove it.
* there’s no spec for a .deb package. This means the only way to correctly generate a Debian package is through the difficult tooling. I understand why this choice is made, and it has a lot of benefits for the continued evolution of the debian project. However, it makes it difficult to build better tooling around deb packages.
Deb/apt might have been nicer to use, but as a packager I found the packaging format extremely horrible to work with.
There's a very complex interaction between the various files which define a package. It's extremely hard to find out what debhelper and its associated commands are actually doing and to debug them, particularly if you're trying to split a package into multiple parts. I gave up several times trying to make my package before finally succeeding with a simplified version. I'm not sure I will understand how it works when I go back to it.
On top of that the sheer volume of rules and regulations, different packaging helpers and out of date suggestions just added to the problem.
Deb has far too much magic. Rpm is much clearer. I can define a simple configuration file which takes the source, patches it, builds it, and describes the packaged files. I've never had a problem understanding an rpm source package.
My first upload will soon be 10 years ago. One thing that is definitely noticeable is that while creating a package is still by no means trivial, it has definitely become much, much easier.
10 years ago, you had a handful of very idiosyncratic build helpers to help you manage your package.
Today, effectively it's just one [1], debhelper, and it has become trivial to build packages with it. It's a very powerful framework that can be overridden do do basically anything you like, but usually automagically does the right thing. Gone are the days where you had to write an unwieldy debian/rules file.
3 years ago, you had X version control systems supported: git, svn, mercurial, cvs, and who nows what else. Sounds unreasonable, right? Well, when you rely on volunteer work, you need to live with the fact that volunteers will choose the particular tooling they like to work with.
Today, you have Salsa which is a GitLab instance, and people apparently just learned to deal with it, and the world hasn't come tumbling down.
I absolutely agree with the author that some things are just wrong within Debian. However, I believe these are inherent to the nature of an organization comprised entirely of volunteers; achieving consensus becomes really hard because nobody wants to be told how to spend their free time.
On the other hand, being involved in Debian has also been an incredibly formative experience. I believe Debian does some things right that others still fail at or trail after.
It doesn't help that many of the official Debian wiki pages contradict eachother in what tools to use or how to use them. It took me a long time of plain experimentation to realize that the debian directory contents are mostly agnostic to what tools you're using to build the package itself, and then it's just figuring out which CLI build tools you can figure out how to get to run (for me it was a combination of cowbuilder + pdebuild, and cowbuilder is optional).
I found it be a big ball of easily forgettable twine of rules tools and oddities myself that every time I needed to redo something was a hassle. With many foot guns that lead to odd package issues.
reply