9 ms·

Here is the solution to this Debian/Gentoo/<other true free software distribution> packager's dilemma. Packagers realize that their numbers are small and they c

Here is the solution to this Debian/Gentoo/<other true free software distribution> packager's dilemma. Packagers realize that their numbers are small and they can't keep up fixing all the modern big software (BS) projects that go against their philosophy. They define the core of the OS that they can keep managing in this traditional way (kernel, basic userland, basic desktop, basic server services, basic libraries, security support for all that). "But people want Firefox, Rust, Kubernetes, modern OS has to provide them". No it doesn't. Let the new complicated juggernaut software be deployed and configured by the users, according to developers' instructions, using whatever modern mechanism they prefer, containers/chroots/light-weight VMs, whatever. Packagers can then forget about the nasty big software and focus on quality of the core OS. Users will have all the newest versions of BS they need from the developers directly. There is no reason to keep fast-pace, ever-changing and very complicated programs/projects in the main OS distribution. It only leads to lots of OS-specific packaging work with mediocre and obsolete results, and that leads to discontent users, developers and packagers.

pvorb 6y ago
Exactly. When you want to install one of those fast-paced pieces of software on your system, you're often dissatisfied with the old version coming with your OS anyway.
- drran 6y ago
  I see no problem to bump versions of a few packages, rebuild them, and install them via system package manager. Are you developer or user? Of course, some software may not work after that, but package manager newer stays in your way, unless you have no idea how to use it.
  - pvorb 6y ago
    I'm a software developer and a user of package managers. A package manager that allows me to only have one version of a software package installed will inevitably get in my way if I need two programs that need different, incompatible versions of that dependency. It happens quite a lot in my experience.
    - drran 6y ago
      Basically, you want to put two versions of the same file(s) into one file. If you need two versions of almost same set of files, then chose different name for the package, e.g. package-2, chose different base directory for package files, e.g. /usr/share/package-2, and chose different names for binaries, e.g. /usr/bin/binary-2. It's not a magic. Just look at examples, e.g. python2 and python3.
      - pvorb 6y ago
        But I'm not the author of those packages. How does the package manager allow me to rename existing packages?
        drran 6y ago
        You can create your own repository, where you will be maintainer of your packages. You can use it locally, as directory on disk, or you can put it on a server and share with others, or you can compile it using openSUSE Build Service, which supports OpenSuSE, SLE, Fedora, RedHat, CentOS, Debian, Arch, etc.: https://en.opensuse.org/openSUSE:Build_Service_supported_build_targets https://en.opensuse.org/openSUSE:Build_Service_supported_bui...
    - Chyzwar 6y ago
      To some extent you can do it with snap. https://snapcraft.io/blog/parallel-installs-test-and-run-multiple-instances-of-snaps https://snapcraft.io/blog/parallel-installs-test-and-run-mul... A lot of discussion here is already solved by snap/flatpack.
tgbugs 6y ago
I think that there is a good reason to keep those projects in the main distribution: it makes them more robust and prevents the build systems and bootstrapping process from becoming a massive pile of technical debt. For example, in order to get clojure 10 running on Gentoo I had to go dig through the git history to figure out where spec-alpha and core-specs-alpha and clojure itself did not form a circular dependency in maven. Because clojure was not being packaged in a variety of ways, they now are at risk of making maven central a hard dependency, which makes the whole project less robust.
- posix_me_less 6y ago
  Do you mean "robust for people using Gentoo" or "robust for everybody"? Isn't the latter responsibility of the Clojure developers rather than packagers?
  - tgbugs 6y ago
    Robust for everyone. In theory it is the responsibility of the Clojure devs, but if there isn't a packaging workflow that they are aware of, how can they be expected to integrate with it and make design and development decisions that it would reveal to them? The point is more that, the greater variety of different environments a piece of software runs in the more likely it is that systematic weaknesses will be revealed, sort of like chaos engineering, except for whole environments instead of sporadic failures.
    - posix_me_less 6y ago
      Yes packaging for different distributions can reveal unknown problems or enhancement possibilities in the project, however I would be surprised if the developers in general were interested at all in supporting that activity. Maybe Clojure is, I don't know. Packaging is beneficial mainly to users, I expect developers to choose single platform and support that, if there is more, great. But most developers aren't interested in a massive distraction that accomodating 520+ distributions is.
wheybags 6y ago
This is why I think the snap store is going the right direction. My web browser and my kernel don't need the same level of attention.
delroth 6y ago
You're making a distinction between "packagers" and "users" which does not exist. Packagers are advanced users that take the initiative to improve their distro when they find software they want to use and that isn't integrated in their distro. > Let the new complicated juggernaut software be deployed and configured by the users, according to developers' instructions, using whatever modern mechanism they prefer I'm not sure what "they" refers to here (developers or users). The existence of packagers is proof that some subset of users "prefer" that software "be deployed and configured" via distro package managers.
- lmm 6y ago
  > The existence of packagers is proof that some subset of users "prefer" that software "be deployed and configured" via distro package managers. Not necessarily. It might be inertia - back when linux distributions started being organised this way, those language dependency management mechanisms pretty much didn't exist.
  - drran 6y ago
    CPAN exists since 1993, online since 1995. CPAN has the package manager, which is able to install perl software with their dependencies. It's not a new, unknown technology. If you are sure that you can create functional, stable, bug free, hole free, up to date, full of useful software distro with 10 independent package managers instead of one, then just do it. We will enjoy it. You will spend about 10x more time than current maintainers, but your time is free, so it's not a problem. Of course, we will say huge THANK YOU for your incredible effort, with nine zeroes after initial zero, except for some hatters, which will blame your perfect distro at HN for no reason.
    - lmm 6y ago
      Debian in particular put a fair bit of effort into integrating apt deeply with CPAN so that you could install a package from there that depended on system libraries and vice versa, and then for subsequent languages they... didn't. You'd think these were well-known technologies, but as far as linux distribution maintaners are concerned they're new and scary. > If you are sure that you can create functional, stable, bug free, hole free, up to date, full of useful software distro with 10 independent package managers instead of one, then just do it. I'd rather leave the distribution model behind entirely. And you know what? I do, and it works great. You just get the occasional complaint like this article, but it doesn't actually matter in the real world.
sanxiyn 6y ago
> basic desktop I actually wish this is feasible, but it isn't. GNOME is basic desktop, GNOME includes librsvg, librsvg build-depends on Rust. So you need to package Rust (hence LLVM) to have GNOME. Your proposal only works if "core OS" refuses to use Rust.
- skybrian 6y ago
  I think it's likely that there will be "system Rust" which is used to compile libraries used by the OS, but this is independent of the toolchain and crates that most developers use for their own development. In a binary distribution, you don't necessarily need to install the system toolchain, unless you want to work on the system.
- posix_me_less 6y ago
  Yeah I get that. GNOME is a horrible big software. I would not count is as "basic desktop", because it is so big, buggy and dependencies are out of control. Basic desktop, I mean something like Xfce, with modular components and minimal dependencies so the desktop system is simple and unixy. You would still have the option to install GNOME on such a system, if only GNOME developers made a canonical version of GNOME that would be modular, and would install on any clean Linux system with Xorg or Wayland.
noobermin 6y ago
That's literally what windows does, for the most part, actually.
- ece 6y ago
  It's the pragmatic thing to do, and it's defacto what happens on Linux distros too. Distros offer pip/docker/cargo, but when some libraries/programs are popular enough, someone will inevitably package it and offer it in a 3rd party repo or the main distro repo. Examples of this would be numpy, ripgrep etc..
symlinkk 6y ago
Agreed, and this is basically the model that macOS / Windows have followed since the dawn of time.

pvorb 6y ago

Exactly. When you want to install one of those fast-paced pieces of software on your system, you're often dissatisfied with the old version coming with your OS anyway.

drran 6y ago
I see no problem to bump versions of a few packages, rebuild them, and install them via system package manager. Are you developer or user? Of course, some software may not work after that, but package manager newer stays in your way, unless you have no idea how to use it.
- pvorb 6y ago
  I'm a software developer and a user of package managers. A package manager that allows me to only have one version of a software package installed will inevitably get in my way if I need two programs that need different, incompatible versions of that dependency. It happens quite a lot in my experience.
  - drran 6y ago
    Basically, you want to put two versions of the same file(s) into one file. If you need two versions of almost same set of files, then chose different name for the package, e.g. package-2, chose different base directory for package files, e.g. /usr/share/package-2, and chose different names for binaries, e.g. /usr/bin/binary-2. It's not a magic. Just look at examples, e.g. python2 and python3.
    - pvorb 6y ago
      But I'm not the author of those packages. How does the package manager allow me to rename existing packages?
      - drran 6y ago
        You can create your own repository, where you will be maintainer of your packages. You can use it locally, as directory on disk, or you can put it on a server and share with others, or you can compile it using openSUSE Build Service, which supports OpenSuSE, SLE, Fedora, RedHat, CentOS, Debian, Arch, etc.: https://en.opensuse.org/openSUSE:Build_Service_supported_build_targets https://en.opensuse.org/openSUSE:Build_Service_supported_bui...
  - Chyzwar 6y ago
    To some extent you can do it with snap. https://snapcraft.io/blog/parallel-installs-test-and-run-multiple-instances-of-snaps https://snapcraft.io/blog/parallel-installs-test-and-run-mul... A lot of discussion here is already solved by snap/flatpack.

tgbugs 6y ago

I think that there is a good reason to keep those projects in the main distribution: it makes them more robust and prevents the build systems and bootstrapping process from becoming a massive pile of technical debt. For example, in order to get clojure 10 running on Gentoo I had to go dig through the git history to figure out where spec-alpha and core-specs-alpha and clojure itself did not form a circular dependency in maven. Because clojure was not being packaged in a variety of ways, they now are at risk of making maven central a hard dependency, which makes the whole project less robust.

posix_me_less 6y ago
Do you mean "robust for people using Gentoo" or "robust for everybody"? Isn't the latter responsibility of the Clojure developers rather than packagers?
- tgbugs 6y ago
  Robust for everyone. In theory it is the responsibility of the Clojure devs, but if there isn't a packaging workflow that they are aware of, how can they be expected to integrate with it and make design and development decisions that it would reveal to them? The point is more that, the greater variety of different environments a piece of software runs in the more likely it is that systematic weaknesses will be revealed, sort of like chaos engineering, except for whole environments instead of sporadic failures.
  - posix_me_less 6y ago
    Yes packaging for different distributions can reveal unknown problems or enhancement possibilities in the project, however I would be surprised if the developers in general were interested at all in supporting that activity. Maybe Clojure is, I don't know. Packaging is beneficial mainly to users, I expect developers to choose single platform and support that, if there is more, great. But most developers aren't interested in a massive distraction that accomodating 520+ distributions is.

wheybags 6y ago

This is why I think the snap store is going the right direction. My web browser and my kernel don't need the same level of attention.

delroth 6y ago

You're making a distinction between "packagers" and "users" which does not exist. Packagers are advanced users that take the initiative to improve their distro when they find software they want to use and that isn't integrated in their distro. > Let the new complicated juggernaut software be deployed and configured by the users, according to developers' instructions, using whatever modern mechanism they prefer I'm not sure what "they" refers to here (developers or users). The existence of packagers is proof that some subset of users "prefer" that software "be deployed and configured" via distro package managers.

lmm 6y ago
> The existence of packagers is proof that some subset of users "prefer" that software "be deployed and configured" via distro package managers. Not necessarily. It might be inertia - back when linux distributions started being organised this way, those language dependency management mechanisms pretty much didn't exist.
- drran 6y ago
  CPAN exists since 1993, online since 1995. CPAN has the package manager, which is able to install perl software with their dependencies. It's not a new, unknown technology. If you are sure that you can create functional, stable, bug free, hole free, up to date, full of useful software distro with 10 independent package managers instead of one, then just do it. We will enjoy it. You will spend about 10x more time than current maintainers, but your time is free, so it's not a problem. Of course, we will say huge THANK YOU for your incredible effort, with nine zeroes after initial zero, except for some hatters, which will blame your perfect distro at HN for no reason.
  - lmm 6y ago
    Debian in particular put a fair bit of effort into integrating apt deeply with CPAN so that you could install a package from there that depended on system libraries and vice versa, and then for subsequent languages they... didn't. You'd think these were well-known technologies, but as far as linux distribution maintaners are concerned they're new and scary. > If you are sure that you can create functional, stable, bug free, hole free, up to date, full of useful software distro with 10 independent package managers instead of one, then just do it. I'd rather leave the distribution model behind entirely. And you know what? I do, and it works great. You just get the occasional complaint like this article, but it doesn't actually matter in the real world.

sanxiyn 6y ago

> basic desktop I actually wish this is feasible, but it isn't. GNOME is basic desktop, GNOME includes librsvg, librsvg build-depends on Rust. So you need to package Rust (hence LLVM) to have GNOME. Your proposal only works if "core OS" refuses to use Rust.

skybrian 6y ago
I think it's likely that there will be "system Rust" which is used to compile libraries used by the OS, but this is independent of the toolchain and crates that most developers use for their own development. In a binary distribution, you don't necessarily need to install the system toolchain, unless you want to work on the system.
posix_me_less 6y ago
Yeah I get that. GNOME is a horrible big software. I would not count is as "basic desktop", because it is so big, buggy and dependencies are out of control. Basic desktop, I mean something like Xfce, with modular components and minimal dependencies so the desktop system is simple and unixy. You would still have the option to install GNOME on such a system, if only GNOME developers made a canonical version of GNOME that would be modular, and would install on any clean Linux system with Xorg or Wayland.

noobermin 6y ago

That's literally what windows does, for the most part, actually.

ece 6y ago
It's the pragmatic thing to do, and it's defacto what happens on Linux distros too. Distros offer pip/docker/cargo, but when some libraries/programs are popular enough, someone will inevitably package it and offer it in a 3rd party repo or the main distro repo. Examples of this would be numpy, ripgrep etc..

symlinkk 6y ago

Agreed, and this is basically the model that macOS / Windows have followed since the dawn of time.