Hacker News Reader

Comment by ymse | Hacker News Reader

As someone who has packaged a lot of software for Debian, CentOS, Gentoo, NixOS, and GNU Guix, I have to agree -- it's by far the most difficult platform.

I actually believe much of the Docker hype can be attributed to this. Why bother learning packaging when you can just script something and throw it in a container.

Now I just use Guix on any distro for my up-to-date/custom software needs.

View on HN

I do recall that Debian packaging, coming from the RPM world, had a very steep learning curve, but that mostly felt like an outsized up-front investment, rather than ongoing pain. (RPM was too long ago to say if it was similar for me).

I'm curious [1] which aspects you find make the Debian (and Ubuntu?) system particularly difficult. Specifically, I wonder if those aspects are difficult by design, in order to "force" effort on the part of the packager to extract benefit on the part of the user or distro, if they're arbitrary, or, perharps if they're by-design but misguided.

[1] No horse in the race.. mostly an end-user whose packaging work is limited to internal-use-only.

There's a big gap between making a working .deb file and getting something to pass QA to get into the archive.

It's been quite a while since I looked at it, but the documentation was fragmented and not up to date. Things have gotten better now you can use git-buildpackage [0], but it still feels arcane.

Challenge - take a package like wget and try to update it to the latest version from upstream Git (or whatever). It should be one or two commands but I've never been able to make it work easily. It's even harder if you're trying to port something across from Ubuntu or to use a fork like wget-lua [1]

0: http://honk.sigxcpu.org/projects/git-buildpackage/manual-htm...

1: https://github.com/alard/wget-lua

> There's a big gap between making a working .deb file and

I assume none of us is even talking about this case. That is, a trivially working .deb could provide little more functionality than a tarball, so that's hardly interesting.

> getting something to pass QA to get into the archive.

The last part I have no knowledge of, since I only ever put my packages into internal archives. Were there political aspects, or only technical?

For the technical, I'm still looking for (ideally from the GP, but from anyone who shares the opinion), specifics.

> the documentation was fragmented and not up to date.

This is a common complaint I hear/read, and I recall it was part of my initial learning investment, figuring out where to go for what information. Now it's mostly bookmarked, and changes tend not to be drastic.

> Things have gotten better now you can use git-buildpackage

One thing I found, repeatedly and consistently, was that every single external (i.e. not from Debian) utility that tried to make the process "better" or "easier" ultimately did the opposite, since it would hide or abstract away an important aspect of the packaging process.

> Challenge - take a package like wget and try to update it to the latest version from upstream Git (or whatever). It should be one or two commands but I've never been able to make it work easily.

I can't recall if I've done wget specifically, but I've done this kind of thing before without much issue, assuming that latest version actually builds and runs on that platform without porting work and without needing a ton of new dependencies (or new versions of existing ones).

I tended to find most of my time was spent in chasing down and re-packaging various libraries whose older versions were no longer good enough.

> It's even harder if you're trying to port something across from Ubuntu

I'm not sure what you mean, since Ubuntu is already using Debian packaging.

> or to use a fork like wget-lua

Certainly forks are going to be more effort, but my experience is that this is true even in their unpackaged state, if they require more exotic (or specific) dependencies be pre-installed, a custom build process, or any porting work. If someone had already done all that work, comprehensively documented it, but merely not translated it into debianization, it would save me a ton of time in creating a custom package.

Would you be willing to share your bookmarks?

Sure. These were approximately chronological order (though Firefox's Sync has occasionally swapped a couple). They're also at least a couple years old, so some may be much older than that and are now dead links without the use of archive.org.

You can somewhat see the evolution of the python package debianization ("python policy").

http://www.debian.org/doc/maint-guide/ch-update.en.html

http://www.gnu.org/software/make/manual/make.html#Automatic-...

http://www.debian.org/doc/debian-policy/

http://www.debian.org/doc/packaging-manuals/python-policy/ap...

http://www.gnu.org/software/make/manual/make.html#Functions

http://www.debian.org/doc/debian-policy/ch-relationships.htm...

http://www.debian.org/doc/debian-policy/ch-maintainerscripts...

http://wings.buffalo.edu/computing/ublinux/Ubuntu.php

http://www.debian.org/doc/developers-reference/

http://webapps-common.alioth.debian.org/draft-wac/html/

http://www.gnu.org/software/make/manual/make.html#Text-Funct...