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.
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.
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.
That is incidentally the most reasonable way to ship a python applications. :D
https://wiki.archlinux.org/index.php/Python_package_guidelin...
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:
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 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.
I can at least tell you that people don't choose Arch over Debian for the installation experience. :)
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.
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.
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.
AUR does have a process to rate, flag and comment on packages. It is also much easier to review the installation script using PKGBUILD. There are a lot of high quality packages in the AUR but you should review everything you install unofficially, just like installing packages from a PPA.
Vendoring is shifting focus back to individual projects though. K8s could almost replace an OS in many regards. It is made to be modular, but only within its own framework. So it is changing the way software is run, similarly to initd and systemd. Such systems as we've seen, tend to "take over" and not be made to be part of and integrate well from inside an OS. Vendoring is really old practice, but also makes testing and support simpler for upstream. We all know the dynamic approach tend to be more unchanging, or associated with several circles of dependency hells.
It's just different end goals for software development and deployment, that affect how software is distributed. Kind of similar to touted goals of JEE of java fame, which also is too monolithic to integrate well within complex systems.
Also, Arch usually puts all files into a single binary package while Debian splits arch-dependent and arch-independent files into separate packages. Also, Debian separates packages into runtime and development libraries, another thing Arch doesn’t do either.
Arch definitely has separate packages for runtime and development libraries. It doesn't have as many, but they exist and can be found by simply searching for `-dev`.
> Arch usually puts all files into a single binary package while Debian splits arch-dependent and arch-independent files into separate packages
Arch has `any` and then architecture specific packages:
https://wiki.archlinux.org/index.php/Arch_package_guidelines...
> Arch doesn’t have to support multiple architectures and releases
https://wiki.archlinux.org/index.php/32-bit_package_guidelin...
There are also distros of Arch for ARM and 32bit, however if you're looking for a more integrated multi-arch PKGBUILD-comparable distro then Alpine is it and probably what I'll be migrating to at some point.
They are an exception to the rule, where the benefits outweights the negatives. It's been done to ensure we have smaller container images, or if the maintaine thinks it makes sense. But as a rule, we do not care while debian does.
>Arch has `any` and then architecture specific packages:
How is the `any` arch related to package splitting?
>https://wiki.archlinux.org/index.php/32-bit_package_guidelin...
> There are also distros of Arch for ARM and 32bit, however if you're looking for a more integrated multi-arch PKGBUILD-comparable distro then Alpine is it and probably what I'll be migrating to at some point.
Those package guidelines exist, but are dated and not used by us, the packagers.
Arch ARM and 32bit are also seperate distirbutions that isn't affiliated with the 64bit Arch Linux distribution.
Leave an arch system without an upgrade for a month and you're playing Russian roulette.
Of course, Debian doesn’t require manual intervention for most updates, but it also isn’t rolling release. If you want packages that are actually recent you have to sit on Sid, which is a lot less stable than Arch. And if you have a Debian machine that’s a couple years old and you want to upgrade it to the latest Debian version? Good luck. Some of that isn’t Debian’s fault, but whereas on Arch major, breaking package changes are rare but irregular, on Debian they tend to hit you simultaneously in one major upgrade. For home machines, I definitely prefer an occasional manual intervention and continuous fixes over major breakages every couple years where I often just give up and reinstall from scratch.
That said I use Arch a lot less nowadays as I’ve moved onto NixOS. Nix is clearly headed somewhere new, though it remains to be seen if the complexity of the approach is actually maintainable.
If I want to make an idiomatic Arch package, it’s usually easy: PKGBUILDs are intuitive and simple. Nix is much the same for most stuff, especially since most of the boilerplate for various build systems has been automated; though for a program as complex as Kubernetes its a nightmare, to be sure. For Dpkg though, it seems like so much complexity, and I don’t think I ever really had a good experience.
And honestly, I have no idea how to make an RPM package anymore.
To counter that with my anecdata, my Debian installations usually outlast the hardware they've been built on. I've found that it's much easier to start new builds with a backup (or the original disk) of the machine they're replacing, that's how easy it is to maintain a Debian system for me.
Heck, my first Linux desktop started out as Ubuntu Breezy, and ended its life as Debian Squeeze. Its replacement started out as Debian Wheezy, and is now on Bullseye.
There are other options. For example, you can sit on stable and get specific packages from unstable, so long as they don't have dependency conflicts with the rest of your system. It requires a little more thought than just running with the defaults, but the docs are pretty clear and detailed (man apt_preferences), and it's mostly a one-time operation. I do this with docker, the kernel, and a maybe a couple other things.
> And if you have a Debian machine that’s a couple years old and you want to upgrade it to the latest Debian version? Good luck.
I guess I'm among the others here who have had good luck, then. The first counterexample that comes to mind is a NAS appliance that is now around ten years old. I replaced its stock OS with debian stable (Squeeze, maybe?) and ran it that way until a year or so past the next stable release, then upgraded. It went fine. I did the same thing repeatedly over the years, until finally decommissioning it last month. It now runs Buster, so that's at least four major version upgrades done past their expiration dates. None of them gave me any trouble. The only thing wrong with it is that my needs have outgrown the hardware.