Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building binary deb packages: a practical guide

internalpointers.com

Post reply on HN
Print view View original

51–60 of 61 posts

Re: Building binary deb packages: a practical guide

#51

Post by hordeallergy »

onli wrote: post #23
NCommander wrote: post #16

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…

The second half of your comment is exactly the experience I recently had when trying for the first time. I quit and built a container image instead.

Re: Building binary deb packages: a practical guide

#52

Post by mehrdadn »

NCommander wrote: post #49
mehrdadn wrote: post #28

Earlier quoted context omitted.

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…

Interesting... by "binary source code" do you mean "binary" (executables)? Do you mean you see distributing binaries as a not-intended use case for .debs, and that they should all result in builds straight from source? Or am I misunderstanding what you're saying? Because I feel like the people who use Debian or Ubuntu (or Arch or Fedora or...) aren't really longing for the experience of building everything from source like Gentoo users might.

Re: Building binary deb packages: a practical guide

#53

Post by Mashimo »

NCommander wrote: post #48
spokspeakspoke wrote: post #27

Earlier quoted context omitted.

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

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

End users can install a deb with one click without having to know about where to put the files, or how to create a shortcut in menu.

Re: Building binary deb packages: a practical guide

#54

Post by GoblinSlayer »

debiandev wrote: post #45
infinity0 wrote: post #4

Earlier quoted context omitted.

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, functiona…

Gatekeeping is the goal of debian packaging documentation? Right, that goal is certainly perfectly achieved.

Re: Building binary deb packages: a practical guide

#55

Post by defanor »

NCommander wrote: post #48
spokspeakspoke wrote: post #27

Earlier quoted context omitted.

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

Not OP, but also packaging binaries into .debs, and the primary reasons for that (as opposed to using tarballs or rsync) are centralized package management, including dependency checks, and scripts to execute on installation (e.g., add system users).

Re: Building binary deb packages: a practical guide

#56

Post by JdeBP »

anttisalmela wrote: post #26

https://vincent.bernat.ch/en/blog/2019-pragmatic-debian-pack...

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

* http://jdebp.uk./FGA/unix-daemon-readiness-protocol-problems...

Re: Building binary deb packages: a practical guide

#57

Post by perlgeek »

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

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

Re: Building binary deb packages: a practical guide

#58

Post by j1elo »

gorgoiler wrote: post #50
debiandev wrote: post #39

Earlier quoted context omitted.

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

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

Re: Building binary deb packages: a practical guide

#59

Post by app4soft »

ghostpepper wrote: post #19
app4soft wrote: post #14

Earlier quoted context omitted.

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

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

> portable meant that software would work on Linux _and_ other platforms.

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

Re: Building binary deb packages: a practical guide

#60

Post by debiandev »

GoblinSlayer wrote: post #54
debiandev wrote: post #45

Earlier quoted context omitted.

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, functiona…

Gatekeeping is the goal of debian packaging documentation? Right, that goal is certainly perfectly achieved.

huh?
Post reply on HN