4 ms·

Compare with Arch, e.g., https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=gf2-git https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=gf2-g..., where y

Compare with Arch, e.g., https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=gf2-git 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.

JNRowe 1y ago
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/ https://joeyh.name/blog/entry/upstream_git_repositories/
- viraptor 1y ago
  Or use FPM and ignore all the official rules. It will still work. https://github.com/jordansissel/fpm https://github.com/jordansissel/fpm
- dundarious 1y ago
  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().
LtWorf 1y ago
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?
- okanat 1y ago
  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.
  - LtWorf 1y ago
    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.
    - umbra07 1y ago
      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.
      - LtWorf 1y ago
        Out of lazyness or out of actual usefulness to the users?
        dpassens 1y ago
        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.

JNRowe 1y ago

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/ https://joeyh.name/blog/entry/upstream_git_repositories/

viraptor 1y ago
Or use FPM and ignore all the official rules. It will still work. https://github.com/jordansissel/fpm https://github.com/jordansissel/fpm
dundarious 1y ago
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().

LtWorf 1y ago

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?

okanat 1y ago
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.
- LtWorf 1y ago
  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.
  - umbra07 1y ago
    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.
    - LtWorf 1y ago
      Out of lazyness or out of actual usefulness to the users?
      - dpassens 1y ago
        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.