Live data from Hacker News

Building binary deb packages: a practical guide

internalpointers.com

41–50 of 61 posts

Re: Building binary deb packages: a practical guide

#41
post #11

Earlier quoted context omitted.

This post describes how to do that, via PPAs: https://is.gd/Eu55IG .

Thanks. That may have been useful to me once, although my motivation was to get my software in the main Debian package set, which I think is quite a different thing from PPAs. Also... look at that guide. Why is it so difficult and obtuse? Why do I have to run so many odd tools, including apparently modifying some file in /etc and running other stuff as root? In contrast, this was my first contribution to Nixpkgs: htt…

Mostly because all of these systems came AFTER Debian.

I mean Debian packaging is a terrible pain - but I have to have empathy with the fact that it's a technical system and more importantly an online community that's been doing it's thing since 1993.

The fact is that with such a long-running system there's more than one way to do everything.

The way we discuss/learn technology has also partly changed. Most of the documentation for Debian is extensive manuals - there's "not enough" intro text, and then "too much" detailed documentation

And then there's the "cost of change". Lots of Debian developers have been packaging using their particular versions of tools for a long time and are happy with them.

In many ways Debian works because the people working on it care about quality and the tooling is second order to the efforts they make.

Re: Building binary deb packages: a practical guide

#42

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…

If deb allowed installation of packages with unmet dependencies, then automatic dependencies could be workable.

Re: Building binary deb packages: a practical guide

#43
post #23

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…

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…

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

Re: Building binary deb packages: a practical guide

#44
post #2

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…

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 assura…

[deleted]

Re: Building binary deb packages: a practical guide

#45
post #2

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…

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 assura…

DD here. The main "barrier" is the level of quality required.

Simply throwing a bunch of files into a package or a container is very quick.

Making an official Debian package is not supposed to be quick. DDs thoroughly review and test the software they are packaging. While packaging I often chase missing licensing information, find plenty of bugs, write systemd unit/init files and sandboxing, write manpages, functional tests, and sometimes find serious vulnerabilities.

I worked on various packaging and deploying systems, and most other distributions don't come anywhere close to this level of scrutiny.

I should also add that becoming a DD requires years of commitment and proven track record of work.

The next time someone complains that making a container is very easy in comparison they should ask themselves: how much can I trust a software source with a very low entry bar?

Re: Building binary deb packages: a practical guide

#46
post #43
post #23

Earlier quoted context omitted.

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…

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

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 :)

Re: Building binary deb packages: a practical guide

#47

Earlier quoted context omitted.

With respect, I think this is a harmful attitude to take. People end up writing huge masses of Puppet/Chef/Ansible, or resorting to heavyweight technologies like Docker, just to place some files on a server. This problem is solved quite well by dpkg since forever, and it's a disservice to the community that this fact is obscured by so much cruft that only distro maintainers really need to know.

Seconded, I tried to package up a publicly available header-only tar.gz into a debian package for our private repo and found it impossible to do. I gave up.

I just stole the process from another project that uses binary packaging.

Re: Building binary deb packages: a practical guide

#48

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…

Been going through the Debian Maintainer process by reading through the Debian official docs. The internalpointers blog post is hand's down more lucid than anything I read on the wiki. I think the other comments here reflect that sentiment.

The best equivalent I can give is this is roughly like opening up a MSI file, and replacing its guts. It works but you're asking for a really fragile system in return.

What is the problem with distributing a tarball if you're sending binaries?

If you're making debs, you still need to make a Debian repo and sign it, and then you still have the problem your dependencies are fucked up or won't easily work across versions.

What are you trying to solve that a tarball or rsync can't?

Re: Building binary deb packages: a practical guide

#49

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…

I've read more than one complaint about Debian's packaging process being a nightmare. I have no horse in the race, but since you're here, I wanted to mention this because it sounds like you're not aware of it (and could possibly help change things).

No, I'm aware it is. Most of the problems is people trying to use it to distribute binary source code. Using it for source builds and debian/rules is a lot saner and straight forward.

These types of debs cause problems with system upgrades and I groan whenever I see something that uses checkinstall or similar; there are add-on deb sites that basically do that, and you get a mess in the resulting system. A lot of this is why snap got made.

I'll admit that the Debian package format could be better in this regard, but the packaging format is primarily for use by dpkg-buildpackage and building the distro.

Disclaimer: this is my own views and not those of either the Debian or Ubuntu projects.

Re: Building binary deb packages: a practical guide

#50

Earlier quoted context omitted.

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.

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.

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?

Post reply on HN