
Building binary deb packages: a practical guide - tblr
https://www.internalpointers.com/post/build-binary-deb-package-practical-guide
======
NCommander
Wow, this is horrible advice. I'm a Debian Developer and an Ubuntu Core
Developer. What this will do is create a package that doesn't properly handle
dependencies and be incredibly fragile.

Debian and Ubuntu automatically resolve shared library dependencies are build
time through dpkg-shlibs and friends. Debian's maintainer manual is likely the
most detailed guide: [https://www.debian.org/doc/manuals/maint-
guide/start.en.html](https://www.debian.org/doc/manuals/maint-
guide/start.en.html)

However, it's a bit hard to grok, so I'm going to point people at the guide
that got linked in the comments before I got here:
[https://saveriomiroddi.github.io/Learn-to-prepare-PPA-
packag...](https://saveriomiroddi.github.io/Learn-to-prepare-PPA-packages-by-
setting-up-a-Ruby-PPA/)

~~~
onli
It's not horrible advice, and none of the links is helpful if you want to
achieve the stated goal in the article: Simply distributing a binary.

It's completely fine to package them in a deb. You especially should know that
debs are really simple and work quite well for that. You place the binary
along with the needed resource files (configuration for example) in the
relative directory structure, add a minimal amount of meta information, and
call one command to create the .deb. Easy and fast, and the result is very
reliable, it will work everywhere.

And then you have the official way of abstraction over abstraction,
"explained" with completely unreadable documentation, needing a dozen helper
tools and environment variables, guided by documentation that fails to explain
even just the basics of what it is you'd actually do if you followed that
documentation.

No, the simple way shown by the submitted article is exactly correct.

Start with that. If it works, then you maybe take the next step later and set
up a PPA, assuming the deb is not only for yourself.

~~~
growse
I think it's bad advice, but not necessarily for the same reason. For the
simple case of "I want to distribute a binary", there are far easier ways to
make a deb - I use FPM, but there are other tools that will also do it in a
one-liner.

For someone new to this, the article's 5-steps are certainly not "practical".

~~~
onli
Well, a binary often needs at least one configuration file, so it's probably
not just that. I think it's easy enough: You just precreate the directory
structure, place the files, add DEBIAN/control, and then it's one command. If
it can be even easier that's really cool :)

------
infinity0
It should be noted that none of this article applies to actual development
that goes on in the Debian distribution from
[https://www.debian.org](https://www.debian.org)

Official Debian development, being FOSS oriented, proceeds from Debian source
packages instead, and one never creates a binary package from scratch as
described in the article. Instead, we use `dpkg-buildpackage` and other
similar tools. The creation of the source package is the hard part, having to
follow all the aspects of Debian policy, including technical matters around
quality.

~~~
dijit
Is there a guide on doing things that way? I've read some of the guides for
making .deb packages (as I had to do so recently) and I have to be honest,
what I encountered was "messy", articles and documentation that would work if
followed but they didn't look even slightly similar.

I'm too embarrassed to even link to the sources that I created.

~~~
pabs3
The official entry point for getting packages into Debian is here:

[https://mentors.debian.net/intro-
maintainers](https://mentors.debian.net/intro-maintainers)

Debian packaging documentation is unfortunately a swamp, since people continue
to write new guides instead of improving existing ones.

------
raziel2p
I still go to FPM
([https://github.com/jordansissel/fpm](https://github.com/jordansissel/fpm))
for any distro-native packaging needs I have.

~~~
app4soft
For user apps on Linux I would prefer to use portable _AppImage_ , instead of
regular packages.

~~~
ghostpepper
I misread your post at first because, once upon a time, portable meant that
software would work on Linux _and_ other platforms.

~~~
app4soft
> _portable meant that software would work on Linux _and_ other platforms._

"portable" and "crossplatform" ("multiplatform") are different degrees of
software.

------
Athas
I think this guide glosses over the most difficult aspect: writing a package
whose executables are generated reasonably reproducibly, using tools from
other Debian packages. I've been a satisfied Debian user for over ten years,
but I gave up on trying to package my own software. I could certainly figure
out how to manually create a `.deb` with an executable and some man pages, but
not how to automate the creation of that `.deb` in a way that lives up to my
expectations of quality.

In contrast, I managed to submit software to Homebrew after two weeks of
macOS, and to Nixpkgs within two _days_ of running NixOS.

~~~
infinity0
As I mentioned in the other comment, the creation of a Debian source package
has a lot of barriers, some of them good and for quality purposes, some of
them bad and due to historical cruft. Documentation is also not very newbie-
friendly. The actual automatic reproduction of a binary from a source package
is simple - `dpkg-buildpackage`.

The tradeoff you get with other distributions being quick, is less quality
assurance. Also, Debian still has a policy of working on 10 architectures, and
this slows things down significantly sometimes. The other distributions you
mentioned don't have this constraint.

~~~
Conan_Kudo
> _The tradeoff you get with other distributions being quick, is less quality
> assurance_

The crux of the problem is that all current official Debian packaging methods
supported by Debian are sufficiently arcane and obtusely documented to the
point that it's a high barrier to entry for people to do it right.

Personally, I've been doing RPM and Debian packaging for over a decade now,
and it boggles the mind how much more complicated doing _correct_ Debian
packaging is for essentially the same that happens on an RPM distribution like
Fedora or openSUSE.

One of the reasons that I started using debbuild[1] for building Debian
packages years ago was that I felt like I could get something that closely
resembled a policy-compliant Debian package without impossible amounts of
guesswork. Combined with macros adapted from Fedora and other distros[2] as an
interface for Debian packaging policies, I can package things rather easily
for Debian/Ubuntu using the much more straightforward guidelines from Fedora
as a base.

As it turns out, it doesn't take that much effort to make packages that comply
with Fedora/openSUSE Packaging Guidelines and Debian Policy with this tool,
and it has drastically simplified my ability to maintain software across
distributions in a way that still cleanly integrates with the distribution
platform.

I wish that debbuild would be an officially supported mechanism in Debian, but
it's probably unlikely without a Debian Developer advocating for it (and I
suspect no one there would, as they probably like the existing system...).

[1]:
[https://github.com/debbuild/debbuild](https://github.com/debbuild/debbuild)

[2]: [https://github.com/debbuild/debbuild-
macros](https://github.com/debbuild/debbuild-macros)

 _(Disclaimer: I am now the current developer of debbuild and debbuild-macros,
though I wasn 't when I first started using it)_

~~~
pabs3
Getting debbuild into Debian would be relatively simple, but getting folks to
switch existing packages away from debhelper is unlikely to be easy.

[https://mentors.debian.net/intro-
maintainers](https://mentors.debian.net/intro-maintainers)

------
anttisalmela
[https://vincent.bernat.ch/en/blog/2019-pragmatic-debian-
pack...](https://vincent.bernat.ch/en/blog/2019-pragmatic-debian-packaging)

~~~
JdeBP
Ironically, that gets the service management wrong.

The memcached people have provided a systemd service unit since 2011, for 8
years at the time that M. Bernat wrote that article. One quite clearly does
_not_ use the -d and -P options, nor Type=forking. memcached is Type=simple
per its authors.

Indeed, Type=forking in a systemd service unit is a good indicator that its
author does not understand service management. It is invariably wrong because
almost _no_ programs actually speak the forking readiness protocol. (They fork
for rather different reasons, which do not in fact adhere to the requirements
of the forking readiness protocol.) See it, and you know to treat
pronouncements about how daemonization works from that source with a great
deal of suspicion.

One such here is "memcached is started with the -d flag and will fork when it
is ready to accept requests". In fact, memcached with -d forks before pretty
much _all_ of its initialization, and _long before it is ready_ to accept
requests. It hasn't even opened its listening sockets, or opened any data
files or started any worker threads, at that point. Client services started
because "memcached is ready" can fail to even connect to it. It might indeed
yet fail whilst initializing, and _never become_ ready.

Really, memcached should have been runnable under inetd as a "wait" service
from the start, which it unfortunately is not. That could have been adapted
into a program that speaks the LISTEN_FDS protocol; and it would have a
memcached.socket unit, with Accept=No and some ListenStream and ListenDatagram
settings, and a Type=simple memcached.service unit. Then clients would have
been able to reliably connect to the socket as soon as the service was
started, and queue up until the service begins to accept() them when it
becomes ready. Early socket opening in action.

* [https://github.com/memcached/memcached/blob/c460f0e13a35dcec...](https://github.com/memcached/memcached/blob/c460f0e13a35dcec26c71311dae6f31acec79f66/scripts/memcached.service)

* [http://jdebp.uk./FGA/unix-daemon-readiness-protocol-problems...](http://jdebp.uk./FGA/unix-daemon-readiness-protocol-problems.html#NooneSpeaksForking)

------
perlgeek
<plug>

I've written a book about Debian packaging that spends most of its page count
on building Debian packages with debhelper/dh, the approach that most (or
all?) official packages use.

Here's a link for the HN crowd to get it for free:
[https://leanpub.com/debian/c/pm](https://leanpub.com/debian/c/pm)

Happy to answer any questions as good as I can :-)

</plug>

------
j1elo
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.

~~~
gorgoiler
Where do Debian maintainers collect their institutional knowledge, these days?

In the past it felt like DSCs uploaded to the FTP queues were the equivalent
of committing code on a software project. Are they all in one git repository
now, that can be tracked outside the project?

Nothing beats being able to read the code for learning how a system actually
works.

~~~
debiandev
DD here.

apt-get install maint-guide ...and then read:

file:///usr/share/developers-reference/index.html file:///usr/share/doc/maint-
guide/html/index.en.html

Also look at existing packages and talk to DDs. Avoid random wikis.

I worked on many deployment systems and reading these guides made me a better
engineer overall.

~~~
gorgoiler
Thanks!

The problem I saw from parent and other posts was that there’s two sets of
information you need to build a package:

(1) the sources and debian patches, where the last public release of these is
available from packages.debian.org

(2) knowing the right command to run to build the package.

In the old days you could guarantee everything would build via dpkg-
buildpackage though you’d need to know to add -r fakeroot.

It sounded like nowadays it’s more complicated than that?

~~~
j1elo
The process itself seems to be very similar if not exactly the same.

The problem is not that, but the way to get there, and how the information is
structured and presented, especially if you start from having no idea, or if
you want to build your debian/ files from a blank slate and being able to read
in a centralized resource about definitions of every line you add (which I
think should be possible to do, for any system in general).

------
mavu
This is better: [https://github.com/phusion/debian-packaging-for-the-
modern-d...](https://github.com/phusion/debian-packaging-for-the-modern-
developer)

(someone with the applicable knowledge please fork and continue it)

------
exabrial
We use the JDeb maven plugin to package up our one-jar. Those are uploaded
using Maven Wagon to a Nexus repository that our Ubuntu servers look at. It's
beautiful how frictionless our deploys are.

