Hacker News Reader

Comment by barumi | Hacker News Reader

> The packaging nightmare is why I left Debian and Ubuntu for Arch.

I find this comment odd and highly dubious. There is absolutely nothing wrong with Debian's packaging system. At most, some individual packages could have been packaged differently, which is arguably a matter of personal taste. Normally, everything just works, and works very well.

Either you shed some additional light on your personal struggles with Debian's packaging, which you did not do at all, or I have to scratch off your baseless assertion as a kin of someone on the internet shouting at clouds.

View on HN

In my experience, once you have a .deb package, it does indeed work perfectly. However, getting to that stage, unless you're packaging a collection of plain files with very simple dependencies, is the hard part.

Ignoring the weird scaffolding you need just to package a static "hello world" binary, there's also all the dh_ scripts which you should use for your package to be "well-made".

I remember looking up how to properly package a Python application, found like 5 different ways documented on the debian wiki, couldn't get any of them to work, gave up and just shipped a whole virtualenv.

This mirrors my experience, too. Building a simple RPM isn't too bad, even if spec files are a little arcane. Packaging for the AUR isn't super complicated as far as I've seen.

The "standard" way to build even the simplest deb file seems super overcomplicated whenever I've tried to do it, with layers of complexity, shims and fudges.

For most simple stuff you just want to specify a bit of metadata, a couple of install scripts and specify "X goes in /usr/bin/X, Y goes in /usr/share/...".

I tend to find that fpm (https://fpm.readthedocs.io/en/latest/) does that for me, and I now use it for building my own deb files pretty much everywhere.

> However, getting to that stage, unless you're packaging a collection of plain files with very simple dependencies, is the hard part.

What do you mean plain files with simple dependencies? A deb file is just a zip that stores metadata and your artifacts exactly where you want then to be in the directory structure you see fit. You specify the packages you depend on in the meditada, zip them up, and that's it.

If you need something fancy you can add shell scripts that are triggered in parts of the installation lifecycle, but those are far from being mandatory.

Hell, if you prefer to follow the lazy way out you can even get build systems to generate your deb files for you. Cmake handles this out-of-the-box.

> Ignoring the weird scaffolding you need just to package a static "hello world" binary

What? That "weird scaffolding" you're referring to is literally the directory you zip with the artifacts in their destination and the metadata! Is it too weird for you to deploy libraries in /use/local/lib before you package them? What are you talking about? You build your static "hello world" binary, you place them in the destination folder, you fill in the metadata to specify dependencies and stuff like your name and email address, and you proceed to zip up the package. Done.

> (...) found like 5 different ways documented on the debian wiki

No you really didn't. At most you found references to 5 different tools that help you do the same exact thing.

Here's a link to a process you tried to described as undecryptable:

https://ubuntuforums.org/showthread.php?t=910717

> You build your static "hello world" binary, you place them in the destination folder, you fill in the metadata to specify dependencies and stuff like your name and email address, and you proceed to zip up the package.

this small "fill in the metadata" part is already half-an-afternoon of reading and understanding all the concepts and mandatory files in there: https://www.debian.org/doc/manuals/maint-guide/dreq.en.html ... and that's only one small part of the manual.

Arch packages in comparison can be a single 15-20 lines PKGBUILD shell script.

The scaffolding I'm referring to is the "debian" directory containing rules, controls etc..

The built-in Debian packaging tools are already wrappers on top of wrappers on top of wrappers, adding another layer on top of that (with Cmake or whatever) only adds to the confusion and goes to show how over-complicated it is.

For example, the article you linked uses dpkg-deb --build while I've seen alternatives use dpkg-buildpackage and debuild.

The 5 different documented ways was specifically referring to Python packages.

There are also helpers like dh_systemd which I could never get to work so just ran systemctl commands in postinst and such.

>>> gave up and just shipped a whole virtualenv.

That is incidentally the most reasonable way to ship a python applications. :D

Debian and Python purists will say otherwise, and there are some reasons not to do it - e.g. wanting to support multiple Python versions across multiple distributions (such as Debian, Ubuntu, and CentOS). But I agree, in my opinion it is the most reasonable way.

Not to ship, but to install using pip if you're doing it outside your system packaging. Here is the recommended approach for Arch:

https://wiki.archlinux.org/index.php/Python_package_guidelin...

It is a recurring theme that whenever Arch proponents mention that they don't like Debian packaging, there is a frustrated reaction to it. But I don't understand what people want to hear; there's clearly a reason why people would choose Debian over Arch, Arch users say packaging is a big part of it, and it seems like nobody can accept that this is right.

I can at least tell you that people don't choose Arch over Debian for the installation experience. :)

The parent was a bit aggressive, but i think asking why the first poster likes arch packages better than debian is a fair question, since that's the interesting part.

> I can at least tell you that people don't choose Arch over Debian for the installation experience

Well, I do (sample of one). The Arch installation has been streamlined a lot. Now it’s all about

0) boot the image (cd, usb, PXE), which is actually an Arch install

a) creating your filesystem (pick you poison), and mounting it

b) telling pacman to install base, base-devel, and a bootloader on the target fs

c) installing and configuring the bootloader

d) rebooting

Done.

d-i barely takes care of that for you, it’s “just” wrapping it behind a UI (which is sort of useful, sure saves one from reading docs, but has been an annoying abstraction/obfuscation/magic layer for me more often than not).

The remainder (setting up X/Wayland/whatever is no different on Debian than on Arch, as d-i does not help much.

Debian supports the same install workflow via debootstrap. You don't have to use d-i.

Debian Developer here. Some people take a very cursory look at Debian and assume the packaging is an exercise in masochism that we inflict on ourselves.

And yet the number of DDs keeps increasing (and Debian is one of most successful projects).

Indeed it takes time to do packaging, and this is by design. Packagers are expected to thoroughly review the code they are packaging and smooth out various sharp corners.

Many times I've found bugs in the upstream code while packaging. Sometimes around security and privacy, often around documentation, usability or non-x86 architectures.

Every time I check if other distributions opened bugs or applied patches for the same issues. It almost never happens.

This is why I might spend 2 hours on a package instead of 10 minutes.

It isn't a cursory look. I worked at Canonical. I used to do lots of Debian packaging. My packages on Arch aren't low-quality. Yet, the packaging process was a lot simpler and a lot more fun on Arch. Plus my package and dependencies are actually based on the stable packages and not a 4 year old patched 10x to maintain compatibility package due to a 3 year old kernel.

Debian packaging is so arcane, I use the arch PKGBUILDs to build the file system tree and one of the deb tools that build a package from a file tree.

I'm a DD, and I can see his point of view. The debian build system started form the simplest thing that would work, and grew from organically from there. Building in the same area as the source for example, and then having to clean the mess up as opposed to just building in a clean temporary directory like rpm did from day 1. We only got clean separation of debian patches from the upstream sources a while ago. Kinda. Sometimes debian has to repackage the upstream sourced due top copyright problems. uscan is hardly a nice solution syntax wise, nor is is policy so there doesn't have to be a fully scripted way of going from upstream source to debian package. And there is the dh sequencer, which splits the configuration into a zillion tiny little files. It goes on.

Like any organic solution it works, and somewhat impressively works for all the use cases created by debian's 60k odd packages. However, pretty or simple it isn't. Learning the interactions of the various dh_ helpers with the build systems they try to automate, the "guesses" (term they use in the manual) they make and when they are applicable is a huge job. The learning hill is consequently steep, and I would say unpleasant.

However, I don't want to undersell the end result. The QA checks done FTP masters, lintian, the discipline imposed by testing and the long transition from testing to stable mean the end result is very, very good. Better than I've seen in any other distro, including the .rpm ones I used to use. From a sysadmin point of view, that trumps everything. From what I can tell debian could be described as a bunch of programmers beavering away for free to produce something that none of them could produce on their own - a Linux distribution so good the base their day jobs on it.

Reply on news.ycombinator.com