4 ms·

Maybe we will finally get some protocol standardization in package distribution. If you think about it it's kind of crazy that we are reinventing the wheel wit

Maybe we will finally get some protocol standardization in package distribution. If you think about it it's kind of crazy that we are reinventing the wheel with every language, OS, game store, extension marketplace etc. A lot of Linux enthusiasts get lost in the idea that there should be one and only one package manager. But actually it's more that there should be a standard protocol for package discovery, distribution and updating; and package managers can just be an interface to those.

Macha 5y ago
> But actually it's more that there should be a standard protocol for package discovery, distribution and updating; and package managers can just be an interface to those. PackageKit exists as a standard protocol on top of myriad package managers. Most major distro package managers (apt, yum/dnf, apk, pacman) have a package kit wrapper, and UI tools such as Gnome Software or KDE Discover exist that use this abstraction. The missing piece here is that it still requires packages to be built in all the different formats that these abstracted package managers require.
noja 5y ago
Exactly. And that one correct true best winning choice can surely only be rpm.
- magpi3 5y ago
  I always wonder how much the split between .deb and .rpm had to do with the names. They serve the exact same function to the point where there is translation software from one to the other and vice versa, but the names themselves promote the distros they were designed for. Is that the biggest reason for the split? Of course the debian project managed the development of .debs and Red Hat managed the development of rpms, so control of that development path was probably another reason. But this is one split in the linux community that really feels unnecessary.
  - stryan 5y ago
    .deb predates RPM's by a few years, so it's probably more then just the name. While they accomplish the same thing, RPM's are actually pretty different from .deb since they're binary files. There's more metadata encoded in the package themselves, as well as a built in signature. .debs are, at their core, still just fancy tarballs organized in a specific manner. Honestly though, RPM's are kind of a mess and pretty difficult to implement without using one of the reference programs, along with containing a lot of extraneous info that you need to fill out. There's a great blog post out there describing someone's attempt to create RPM's from scratch and their gradual descent into insanity. Though, the extra metadata has it's features (better search, dependency resolution, etc).
    - wichert 5y ago
      It has probably been 20 years since I did anything with deb and rpm, but I think this still holds true: The deb and rpm formats had a very different philosophy to handling dependencies: the deb format relies completely on package names, while the rpm format also allows you depend on the existing of files (or other things?). That implies that the doing/deb ecosystem only works if you manage the entire OS, while rpm (at least theoretically) allows you to use rpms in a system managed in some other way. Of course that capability in the package format itself did not mean people used that. The file formats are also slightly different: dpkg/deb is completely build using tar and ar, while rpm is a custom binary based on cpio. That also made the deb format flexible enough to not have needed any changes in 30 years, which is pretty amazing. The source formats have a lot more differences, but I don’t know enough about those. From what I remember srpm used to be more powerful, but Debian’s source format has caught up by now. A nice side effect of only Debian using dpkg/deb, at least historically, was that when you got a deb file it was guaranteed to work on your Debian system, but for an rpm you could never predict if it would work on your RedHat/SuSe/Mandriva/TurboLinux/etc. system.
ziggus 5y ago
There's already a standard that's been in place for ages and ages: ./configure make make install
- jcelerier 5y ago
  it's not a useful standard if it does not work out-of-the-box on a native windows install
- lhorie 5y ago
  That's just for building though, isn't it? Package managers these days deal w/ network, registries, version management, transitive dependency resolution, etc. Not to mention Windows.
- chrisseaton 5y ago
  I'm not sure that's what people mean by package management. For example if a configure script has a dependency on a library... then what? It doesn't help me find and install the right version of that dependency, does it? In my experience it just says 'dependency not installed'.
  - klyrs 5y ago
    I think it's meant as a joke, but for many of us, there's some truth to it. If you're missing a dependency, you'll need to download, configure, make, install it.
    - chrisseaton 5y ago
      > If you're missing a dependency, you'll need to download, configure, make, install it. Right but people want their package managers do this for them. That’s the whole point.
      - klyrs 5y ago
        That's what indicates to me that it was intended as a joke, yes.
HeyImAlex 5y ago
I think you’re overestimating how generic package management is. They’re very tightly coupled to their respective languages and build systems.
- scrollaway 5y ago
  I worked on the problem for two years. I'm not overestimating anything; it's just that the wrong targets are being set. Like I said in my post, it's a "single package manager to rule them all" is the wrong goal. What you want is a common protocol, and multiple implementations of it. "I want an app store" = spin up your favourite PackManProtocol server, configure it to your needs, done. The basics of package management are all very similar and can be covered by core use cases. The solution would need to be extensible enough to be usable beyond those. But having restrictions can also be good for an ecosystem (preventing weird-feature creep).
yissp 5y ago
http://xkcd.com/927/ http://xkcd.com/927/ sorry, but I had to
- javajosh 5y ago
  Upvoted because it needs repeating. And also https://xkcd.com/1053/ https://xkcd.com/1053/

Macha 5y ago

> But actually it's more that there should be a standard protocol for package discovery, distribution and updating; and package managers can just be an interface to those. PackageKit exists as a standard protocol on top of myriad package managers. Most major distro package managers (apt, yum/dnf, apk, pacman) have a package kit wrapper, and UI tools such as Gnome Software or KDE Discover exist that use this abstraction. The missing piece here is that it still requires packages to be built in all the different formats that these abstracted package managers require.

noja 5y ago

Exactly. And that one correct true best winning choice can surely only be rpm.

magpi3 5y ago
I always wonder how much the split between .deb and .rpm had to do with the names. They serve the exact same function to the point where there is translation software from one to the other and vice versa, but the names themselves promote the distros they were designed for. Is that the biggest reason for the split? Of course the debian project managed the development of .debs and Red Hat managed the development of rpms, so control of that development path was probably another reason. But this is one split in the linux community that really feels unnecessary.
- stryan 5y ago
  .deb predates RPM's by a few years, so it's probably more then just the name. While they accomplish the same thing, RPM's are actually pretty different from .deb since they're binary files. There's more metadata encoded in the package themselves, as well as a built in signature. .debs are, at their core, still just fancy tarballs organized in a specific manner. Honestly though, RPM's are kind of a mess and pretty difficult to implement without using one of the reference programs, along with containing a lot of extraneous info that you need to fill out. There's a great blog post out there describing someone's attempt to create RPM's from scratch and their gradual descent into insanity. Though, the extra metadata has it's features (better search, dependency resolution, etc).
  - wichert 5y ago
    It has probably been 20 years since I did anything with deb and rpm, but I think this still holds true: The deb and rpm formats had a very different philosophy to handling dependencies: the deb format relies completely on package names, while the rpm format also allows you depend on the existing of files (or other things?). That implies that the doing/deb ecosystem only works if you manage the entire OS, while rpm (at least theoretically) allows you to use rpms in a system managed in some other way. Of course that capability in the package format itself did not mean people used that. The file formats are also slightly different: dpkg/deb is completely build using tar and ar, while rpm is a custom binary based on cpio. That also made the deb format flexible enough to not have needed any changes in 30 years, which is pretty amazing. The source formats have a lot more differences, but I don’t know enough about those. From what I remember srpm used to be more powerful, but Debian’s source format has caught up by now. A nice side effect of only Debian using dpkg/deb, at least historically, was that when you got a deb file it was guaranteed to work on your Debian system, but for an rpm you could never predict if it would work on your RedHat/SuSe/Mandriva/TurboLinux/etc. system.

ziggus 5y ago

There's already a standard that's been in place for ages and ages: ./configure make make install

jcelerier 5y ago
it's not a useful standard if it does not work out-of-the-box on a native windows install
lhorie 5y ago
That's just for building though, isn't it? Package managers these days deal w/ network, registries, version management, transitive dependency resolution, etc. Not to mention Windows.
chrisseaton 5y ago
I'm not sure that's what people mean by package management. For example if a configure script has a dependency on a library... then what? It doesn't help me find and install the right version of that dependency, does it? In my experience it just says 'dependency not installed'.
- klyrs 5y ago
  I think it's meant as a joke, but for many of us, there's some truth to it. If you're missing a dependency, you'll need to download, configure, make, install it.
  - chrisseaton 5y ago
    > If you're missing a dependency, you'll need to download, configure, make, install it. Right but people want their package managers do this for them. That’s the whole point.
    - klyrs 5y ago
      That's what indicates to me that it was intended as a joke, yes.

HeyImAlex 5y ago

I think you’re overestimating how generic package management is. They’re very tightly coupled to their respective languages and build systems.

scrollaway 5y ago
I worked on the problem for two years. I'm not overestimating anything; it's just that the wrong targets are being set. Like I said in my post, it's a "single package manager to rule them all" is the wrong goal. What you want is a common protocol, and multiple implementations of it. "I want an app store" = spin up your favourite PackManProtocol server, configure it to your needs, done. The basics of package management are all very similar and can be covered by core use cases. The solution would need to be extensible enough to be usable beyond those. But having restrictions can also be good for an ecosystem (preventing weird-feature creep).

yissp 5y ago

http://xkcd.com/927/ http://xkcd.com/927/ sorry, but I had to

javajosh 5y ago
Upvoted because it needs repeating. And also https://xkcd.com/1053/ https://xkcd.com/1053/