6 ms·

Debian doesn't do a good job in making life easier for its maintainers. https://michael.stapelberg.ch/posts/2019-03-10-debian-winding-down/ https://michael.stap

by Piraty 2y ago

Debian doesn't do a good job in making life easier for its maintainers. https://michael.stapelberg.ch/posts/2019-03-10-debian-winding-down/ https://michael.stapelberg.ch/posts/2019-03-10-debian-windin...

imtringued 2y ago
I made my own custom packages for Alpine Linux and Arch Linux for personal use. It is so easy that I am honestly I'm not seeing the point in doing things the way Debian does it. It just makes things unnecessarily difficult for no reason. What does a maintainer realistically do? He builds the software, so you expect that the package builder automatically installs the development dependencies and runs the build software inside a chroot. In case the software requires modifications, there needs to be a way to deliver patch files or additional files that aren't part of the original software or at least a standard location to store the distro specific fork that everyone agrees on. Once the software is built, the maintainer creates a directory structure that conforms to the distributions's conventions, adds things like systemd unit files or desktop shortcuts and other distro specific changes that exist outside the software. I would encourage everyone to at least give Alpine or Arch Linux packaging a try. It really is quite easy. Almost as easy as writing a docker file.
- sangnoir 2y ago
  > What does a maintainer realistically do? Debian maintainers have to coax upstream packages to behave like other Debian packages and use supported linked dependencies. This covers everything from log and config file locations, startup scripts patching dependencies to match the versions supported by the release, backporting security updates, and documenting. I trust Debian (and in turn Debian maintainers) more than I trust the upstream developer of lib-random-4-dev. I only ever had to build a custom package from source a handful of times.
  - homebrewer 2y ago
    Simpler packaging formats like pkgbuild and apkbuild do all of that too. They're easier to use because they do away with "convenient" automation that makes simple things trivial, and slightly more complex things very difficult. You just use the shell with all the standard commands.
    - sangnoir 2y ago
      > Simpler packaging formats like pkgbuild and apkbuild do all of that too. I don't doubt it: isn't the breadth of Linux distro flavors and philosophies an amazing thing?
- Piraty 2y ago
  I agree and add Void Linux to the list in the same vein. Generalley, ports-like package repos (all package build recipes in one repo) are really beneficial for large-scale operations or simply rollbacks. Being able to bootstrap the distro from a git repo and a well-defined set of bootstrap tools is really nice. try that with debian. See Void Linux and Alpine for a simple, yet refreshing aproach to distro package maintenance, with low overhead.
- homebrewer 2y ago
  > Almost as easy as writing a docker file. It's easier because you get a sane shell instead of a poor reimplementation of a tiny subset of one. I maintain many aur packages, and wrote the first one in half an hour, knowing nothing about Arch packaging at the time. Now it takes me maybe 5-10 minutes to package a small application that adheres to the standard conventions. I spent maybe two days on my first Debian package. It was also the last one (not really, but almost so).
bityard 2y ago
I can't find it now, but I read something just a few days ago saying that some prominent Debian members very much want to see the development/maintainership experience of the OS modernized and improved. They are suggesting (but not demanding) that packages be maintained by teams rather than individuals, manage source packages on Debian's own Gitlab instance, accept issues and PRs via Gitlab, better CI and testing infrastructure for packages, and so on. I respect the fact that current Debian development practices have carried the OS this far, but lowering the barrier to entry for volunteers to help maintain the OS going forward could only be a good thing.
- JonChesterfield 2y ago
  Lowering the bar to entry in software can absolutely be a bad thing in a wide range of ways. The most obvious in the current context is possibly well intentioned amateurs proposing LLM generated patches for the usual developers to fritter away their time on until patience runs out.
  - bityard 2y ago
    I suppose that _could_ happen, but I don't see it as very likely. Maintainers are absolutely free to decline low-quality patches or ignore with contributors who expect an unreasonable amount of hand-holding. This is completely independent of whether the code was generated by an LLM or human. I have seen maintainers who, after a few rounds of code review on a PR that's not making any progress, close the PR and say, "I appreciate your efforts but this is taking up too much time. Please address the remaining issues independently and submit a new PR once you believe you have addressed them all." The other possibility is that the LLM-generated patch is actually fine. If it looks okay and passes the automated tests, then I can't see why it shouldn't be merged. (Assuming Debian doesn't or hasn't enacted a blanket-ban on LLM-generated code.)
- homebrewer 2y ago
  https://lwn.net/Articles/986480/ https://lwn.net/Articles/986480/

by Piraty 2y ago

imtringued 2y ago

I made my own custom packages for Alpine Linux and Arch Linux for personal use. It is so easy that I am honestly I'm not seeing the point in doing things the way Debian does it. It just makes things unnecessarily difficult for no reason. What does a maintainer realistically do? He builds the software, so you expect that the package builder automatically installs the development dependencies and runs the build software inside a chroot. In case the software requires modifications, there needs to be a way to deliver patch files or additional files that aren't part of the original software or at least a standard location to store the distro specific fork that everyone agrees on. Once the software is built, the maintainer creates a directory structure that conforms to the distributions's conventions, adds things like systemd unit files or desktop shortcuts and other distro specific changes that exist outside the software. I would encourage everyone to at least give Alpine or Arch Linux packaging a try. It really is quite easy. Almost as easy as writing a docker file.

sangnoir 2y ago
> What does a maintainer realistically do? Debian maintainers have to coax upstream packages to behave like other Debian packages and use supported linked dependencies. This covers everything from log and config file locations, startup scripts patching dependencies to match the versions supported by the release, backporting security updates, and documenting. I trust Debian (and in turn Debian maintainers) more than I trust the upstream developer of lib-random-4-dev. I only ever had to build a custom package from source a handful of times.
- homebrewer 2y ago
  Simpler packaging formats like pkgbuild and apkbuild do all of that too. They're easier to use because they do away with "convenient" automation that makes simple things trivial, and slightly more complex things very difficult. You just use the shell with all the standard commands.
  - sangnoir 2y ago
    > Simpler packaging formats like pkgbuild and apkbuild do all of that too. I don't doubt it: isn't the breadth of Linux distro flavors and philosophies an amazing thing?
Piraty 2y ago
I agree and add Void Linux to the list in the same vein. Generalley, ports-like package repos (all package build recipes in one repo) are really beneficial for large-scale operations or simply rollbacks. Being able to bootstrap the distro from a git repo and a well-defined set of bootstrap tools is really nice. try that with debian. See Void Linux and Alpine for a simple, yet refreshing aproach to distro package maintenance, with low overhead.
homebrewer 2y ago
> Almost as easy as writing a docker file. It's easier because you get a sane shell instead of a poor reimplementation of a tiny subset of one. I maintain many aur packages, and wrote the first one in half an hour, knowing nothing about Arch packaging at the time. Now it takes me maybe 5-10 minutes to package a small application that adheres to the standard conventions. I spent maybe two days on my first Debian package. It was also the last one (not really, but almost so).

bityard 2y ago

I can't find it now, but I read something just a few days ago saying that some prominent Debian members very much want to see the development/maintainership experience of the OS modernized and improved. They are suggesting (but not demanding) that packages be maintained by teams rather than individuals, manage source packages on Debian's own Gitlab instance, accept issues and PRs via Gitlab, better CI and testing infrastructure for packages, and so on. I respect the fact that current Debian development practices have carried the OS this far, but lowering the barrier to entry for volunteers to help maintain the OS going forward could only be a good thing.

JonChesterfield 2y ago
Lowering the bar to entry in software can absolutely be a bad thing in a wide range of ways. The most obvious in the current context is possibly well intentioned amateurs proposing LLM generated patches for the usual developers to fritter away their time on until patience runs out.
- bityard 2y ago
  I suppose that _could_ happen, but I don't see it as very likely. Maintainers are absolutely free to decline low-quality patches or ignore with contributors who expect an unreasonable amount of hand-holding. This is completely independent of whether the code was generated by an LLM or human. I have seen maintainers who, after a few rounds of code review on a PR that's not making any progress, close the PR and say, "I appreciate your efforts but this is taking up too much time. Please address the remaining issues independently and submit a new PR once you believe you have addressed them all." The other possibility is that the LLM-generated patch is actually fine. If it looks okay and passes the automated tests, then I can't see why it shouldn't be merged. (Assuming Debian doesn't or hasn't enacted a blanket-ban on LLM-generated code.)
homebrewer 2y ago
https://lwn.net/Articles/986480/ https://lwn.net/Articles/986480/