Hacker News Reader

Comment by dundarious | Hacker News Reader

Compare with Arch, e.g., https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=gf2-g..., where you just run `makepkg` or `makechrootpkg -r ~/archroot` (setup is just `mkdir -p ~/archroot ; mkarchroot ~/archroot/root base-devel`). The wiki is also wonderful (even for general-linux/non-Arch-specific information) -- informative and to-the-point.

View on HN

To be fair, if all you want is a package with Debian you can do that too. Just copy files in to a dir(like package() in your Arch example), write a 10 line DEBIAN/control in there(like the preamble in your Arch example), and call "dpkg-deb --build". The linked document is describing something different, joeyh has a short "why?"¹ from years ago that may be helpful.

¹ https://joeyh.name/blog/entry/upstream_git_repositories/

Or use FPM and ignore all the official rules. It will still work. https://github.com/jordansissel/fpm

What is different in OP that makes that approach not suitable? The git upstream? In the AUR example I gave, pkgver() auto-updates $pkgver, which will show up in version control. You can run `makepkg -defo` (or -dfo I forget which rn) to just run pkgver().

And will arch tell you that the package has updated the configuration and that you might want to review your canges with the changes from the new version?

Will it automatially restart the .service file of the daemon you just upgraded? Will it autodetect which python modules it requires to install?

Arch/pacman will tell you config changes. There is even an utility called pacdiff to review all of them at once. It will not restart service files since it is a more hands-on distro. Since Arch is a quick rolling-release distro, it is better to reboot your system since ABI stability is not guaranteed.

Arch/pacman packages are quite simple which makes the maintenance burden less. However, when compared to more mainstream distros like OpenSUSE and Fedora, Debian's package recipes are more unwieldy and arcane. Why do we need to put things in the upstream source in the first place? Why do we use scripts that don't make sense and full of legacy in 2025?

I deal with Yocto almost daily, still most Debian packages are a mistery to me. Don't even mention things like getting an almost upstream Linux kernel (like a vanilla release + some patches on top) to be ported as a normal Debian package.

Is telling systemd to reload .service files after changing them a "script that doesn't make sense" to you?

Makes plenty of sense to me.

90% of the scripts are to do that, or to recompile .pyc files when you install a new module or when you install a new version of python.

Arch tries to generally avoid changing "default" behavior. Systemd doesn't automatically do that, so Arch won't ship systemd like that. Arch also generally avoids shipping with timers enabled.

Out of lazyness or out of actual usefulness to the users?

I personally (using Arch, btw) definitely prefer Arch's behaviour. If I update or install a daemon, I generally want to configure it before (re)starting it.

Restarting it and telling systemd the .service unit has been changed aren't the same thing.

Arch does daemon-reload after service file update: `(2/5) Reloading system manager configuration...`

A little of column A, a little of column B. Arch is very much a distro developed for the packagers. OTOH, as someone who often has to dive into the details regardless of distro, I generally appreciate the plain-vanilla approach to arch's packaging (since I can just set the package up as opposed to undoing whatever helpful defaults and changes Debian's decided to add).

Arch does reload service files (not user ones though) IIRC. I also disagree with GP, I don't reboot, I use needsrestart and/or my own logic (simple grep for "(deleted)" within proc maps and then show cmdline).

1. If you mean merging package/upstream config with user/system modified config, yes, run pacdiff

2. Use needsrestart (isn't this what Debian uses also?)

3. I don't package python things, I wouldn't know. Maybe, maybe not.

Do the above have different trade offs that are not best fit for everyone? Yes, of course. I used Debian for about a decade, and Arch for almost as long, and have found everything clear and well documented. All the various functionality I want is typically implemented by a simple tool designed for that one job, with a nice wiki page/entry that I could find trivially.

I did not write my post in order to start a "distribution debate". I had the sense that the contents of debian/ in the OP were not fully given, because there was a lot there, and I wanted to know if that was true, and if so, why. Having a pretty short and self-explanatory single file alternative to look at might prompt someone to pipe up and say "look, the Debian equivalent is short/long/simple/complex" in a clear way, which would be interesting because I consider such Arch examples to be near ideal.

Reply on news.ycombinator.com