4 ms·

This release is particularly exciting because it’s the first to include the Fedora Modularity feature across all our different variants. Modularity lets us ship

This release is particularly exciting because it’s the first to include the Fedora Modularity feature across all our different variants. Modularity lets us ship different versions of packages on the same Fedora base. This means you no longer need to make your whole OS upgrade decisions based on individual package versions. For example, you can choose Node.js version 8 or version 10, on either Fedora 28 or Fedora 29. Or you can choose between a version of Kubernetes which matches OpenShift Origin, and a module stream which follows the upstream. I continue to be bewildered by the idea that this should be a foreign concept, that individual third-party software versions should not be tied directly to OS update releases. Literally no operating system works like this except Linux. At least Fedora is more prompt about keeping up to day than other distros.

elcomet 8y ago
This is because packages relie on each other to work. They don't just bundle all their dependencies. So maintainers have to update package based on the dependancies version that are in the repositories. Every package updating alone (or updating all its dependancies) might make everything break on the system. So there is a compromise here to get smaller packages, that don't bundle everything but reuse other packages. If you want packages that bundle everything, then you can use snap / flatpack, they are exactly designed for this.
- jarcane 8y ago
  The only reason this is even an issue is because Linux distros insist on clinging to dynamic linking absolutely everything, out of some outdated 90s-era assumptions about disk conservation, and package availability. Because often in those days downloading new packages wasn't an option because you might not even have internet at home, distros just bundled every known bit of software they could think of on the CD (Remember Walnut Creek?). But it's 2018. Even cell phone 3G is fast enough to deal with Linux deps. Disks are huge outside embedded spaces where the last thing you want to do is install a zillion random Linux deps anyway. Literally every programming language on the planet has tools to manage dependencies per-project, and it's best practice to lock a known good version of any libraries for a program anyway. Which means the only remaining concern is system-level compatibility issues, which shouldn't be a problem for normal userland software anyway, and if anything should allow for and expect failure. It's not something you should be tying the entire OS release and update cycle to for your entire software ecosystem. And yet, despite years of Linus screaming "DON'T BREAK USERLAND", distros still are built, and almost have to be built, on the assumption that everything is an interdependent house of cards that could break at any time. And the disk space arguments that consumed Usenet for years on end have become meaningless anyway, because software winds up having to link to specific versions of libs anyway, so most distros have to maintain a bunch of separate version packages anyway. Like I said: no other OS has this problem to this degree. OS X, Windows, hell even FreeBSD keeps pkg/ports distinct from the core system. I have never on any of these had to wait six months or side load just to get an up-to-date version of my tools. And we all know this: why do you think every damn language has its own package manager now? Why everyone has to maintain a ~/.local/bin, and indeed: why snap/flatpack ever had to exist in the first place. tl;dr: I know damn well why it is this way, but it's dumb, and while I'm glad someone's finally fixing it, that doesn't make it any less baffling it took this many years to do so.
  - elcomet 8y ago
    That's very interesting, thanks for the insight! Do you know any Linux distros that try to solve this issue, outside fedora here?
    - pfranz 8y ago
      I'm not sure if it would address his needs, but NixOS takes a different approach. The package manager, Nix, can run in a Linux environment or even macOS. GNU Guix is another variant of it. I've played around with it and really liked it, but it's mostly been false starts when trying to do anything serious. I understand why there's a DSL, but I had trouble groking it enough to build my own stuff.
  - pfranz 8y ago
    I know nothing about this Fedora tech (but am really curious). Windows and macOS don't mix libraries and Applications with a packaging system and Linux distros do. I've always felt like the packaging systems for each OS had very different goals and most all of the Linux distro's packaging systems had way too much overlap to warrant different tech. When you're talking about packaging systems for macOS and Windows are you talking about things like Homebrew/Chocolatey or their interface for installing applications? I just don't see other OSes handling these things any better. I've been in the camp that language-specific package managers shouldn't have to be a thing. I'm on your side in that I think it's ridiculous that package managers have belligerent towards language-specific package managers (they'll package up libraries for languages, but not change their packaging system to address the needs they were trying to fill). Like you, I maintain my own ~/.local/bin and it sucks because the next thing I want to do is message the guy next to me and say, "run this." Instead, I have to explain how to build or install everything I just did and troubleshoot any problems. But I don't see any benefits for Windows or macOS for doing this. At larger vfx and animation studios, they all have their own packaging system they've written to manage a project's tools (here's one that's been Open Sourced[1]). I've also wanted alternative approaches, like Nix, to gain popularity. [1] https://github.com/nerdvegas/rez https://github.com/nerdvegas/rez
  - grumpydba 8y ago

elcomet 8y ago

This is because packages relie on each other to work. They don't just bundle all their dependencies. So maintainers have to update package based on the dependancies version that are in the repositories. Every package updating alone (or updating all its dependancies) might make everything break on the system. So there is a compromise here to get smaller packages, that don't bundle everything but reuse other packages. If you want packages that bundle everything, then you can use snap / flatpack, they are exactly designed for this.

jarcane 8y ago
The only reason this is even an issue is because Linux distros insist on clinging to dynamic linking absolutely everything, out of some outdated 90s-era assumptions about disk conservation, and package availability. Because often in those days downloading new packages wasn't an option because you might not even have internet at home, distros just bundled every known bit of software they could think of on the CD (Remember Walnut Creek?). But it's 2018. Even cell phone 3G is fast enough to deal with Linux deps. Disks are huge outside embedded spaces where the last thing you want to do is install a zillion random Linux deps anyway. Literally every programming language on the planet has tools to manage dependencies per-project, and it's best practice to lock a known good version of any libraries for a program anyway. Which means the only remaining concern is system-level compatibility issues, which shouldn't be a problem for normal userland software anyway, and if anything should allow for and expect failure. It's not something you should be tying the entire OS release and update cycle to for your entire software ecosystem. And yet, despite years of Linus screaming "DON'T BREAK USERLAND", distros still are built, and almost have to be built, on the assumption that everything is an interdependent house of cards that could break at any time. And the disk space arguments that consumed Usenet for years on end have become meaningless anyway, because software winds up having to link to specific versions of libs anyway, so most distros have to maintain a bunch of separate version packages anyway. Like I said: no other OS has this problem to this degree. OS X, Windows, hell even FreeBSD keeps pkg/ports distinct from the core system. I have never on any of these had to wait six months or side load just to get an up-to-date version of my tools. And we all know this: why do you think every damn language has its own package manager now? Why everyone has to maintain a ~/.local/bin, and indeed: why snap/flatpack ever had to exist in the first place. tl;dr: I know damn well why it is this way, but it's dumb, and while I'm glad someone's finally fixing it, that doesn't make it any less baffling it took this many years to do so.
- elcomet 8y ago
  That's very interesting, thanks for the insight! Do you know any Linux distros that try to solve this issue, outside fedora here?
  - pfranz 8y ago
    I'm not sure if it would address his needs, but NixOS takes a different approach. The package manager, Nix, can run in a Linux environment or even macOS. GNU Guix is another variant of it. I've played around with it and really liked it, but it's mostly been false starts when trying to do anything serious. I understand why there's a DSL, but I had trouble groking it enough to build my own stuff.
- pfranz 8y ago
  I know nothing about this Fedora tech (but am really curious). Windows and macOS don't mix libraries and Applications with a packaging system and Linux distros do. I've always felt like the packaging systems for each OS had very different goals and most all of the Linux distro's packaging systems had way too much overlap to warrant different tech. When you're talking about packaging systems for macOS and Windows are you talking about things like Homebrew/Chocolatey or their interface for installing applications? I just don't see other OSes handling these things any better. I've been in the camp that language-specific package managers shouldn't have to be a thing. I'm on your side in that I think it's ridiculous that package managers have belligerent towards language-specific package managers (they'll package up libraries for languages, but not change their packaging system to address the needs they were trying to fill). Like you, I maintain my own ~/.local/bin and it sucks because the next thing I want to do is message the guy next to me and say, "run this." Instead, I have to explain how to build or install everything I just did and troubleshoot any problems. But I don't see any benefits for Windows or macOS for doing this. At larger vfx and animation studios, they all have their own packaging system they've written to manage a project's tools (here's one that's been Open Sourced[1]). I've also wanted alternative approaches, like Nix, to gain popularity. [1] https://github.com/nerdvegas/rez https://github.com/nerdvegas/rez
- grumpydba 8y ago