4 ms·

Package management isn't realistic unless you only pick a few distros to support -- and then you get criticized for not supporting every distro, some of the dis

Package management isn't realistic unless you only pick a few distros to support -- and then you get criticized for not supporting every distro, some of the distros end up way behind on the version, some of them modify your code to make it fit better in their system...

Eleison23 4y ago
[dead]
saghm 4y ago
Lately I've been coming around to the idea that AppImage is the best middle ground we have so far. Basically, it lets you provide static binary for people to download and use as-is if their repos don't have it available but then bundles in special flags starting with `--appimage-` for stuff like extracting the bundle libraries/assets into a directory structure that's the same for every AppImage. It seems like it's a step in the direction towards being able to automate making packages for various distros; It would be a tough design problem but really amazing if the format being expanded to be able to include source files so that each package manager could write their own plugins for converting the extracted AppImage into their own package format (appimage2deb, appimage2rpm, etc.). Maybe AppImage isn't the right basis for this sort of thing, but instead of trying to drive adoption of distro agnostic package managers which will face resistance from distro maintainers, I feel like the right solution would be something that provides for distros what LSP provided for editors and what LLVM provided for compiler authors. We're not lacking in package managers as a community, but we really could use a standard protocol or intermediate layer that _doesn't _ try to replace existing package managers but instead works with and relies upon them in a way that benefits everyone.
- aprdm 4y ago
  It’s worth noting that some big companies have something like what you describe. I was building packages for one and it’s basically reverse engineering however something is packed (e.g an RPM) and making it build/bundle in the way big corp operates. It’s a lot of busy work but we guaranteed that we had all dependencies in house and that the same package had the same layout of files across every OS
  - saghm 4y ago
    I guess my hope is that rather than requiring a bunch of hardcoded boilerplate for each package management solution, we could come up with a reasonable set of primitives that they'd all need and then find a way to express them agnostically. The power of LLVM and LSP are that it's not just one entity producing all of the implementations, but that each side of the communication can contribute the stuff that's specific to their use case so that no one else needs to worry about those internal details. If I write a new programming language, all I need to do is implement a language server client, and then everyone can get plugins for pretty much any editor they want without needing to do a huge amount of work. It's possible something like this exists for package management right now, but my current impression is that the only products that try to provide something like this would not be as easily extensible to adding new distro package formats that might be invented but instead hardcode a few of the most common types (debian, rpm, etc.). The key part that seems to be missing is a standard for what the bits in the middle should look like; what's the package-level equivalent to LLVM IR or the LSP?
Ferret7446 4y ago
Hence the existence of flatpak and similar.
blacklion 4y ago
Author should not be packager. Distro users/maintainers should be packagers. Look at FreeBSD ports: there are more than 25K packages, most of them with latest upstream versions. How much of these packages are prepared by authors? Maybe, 1 in 1000 (I'm optimist, I know). NetBSD's pkgsrc is the same. It works. Authors better stick to traditional UNIX-style build system, which allows to pickup dependencies from local system without problems, and all distro-specific thing will be done by distro guys. I've ported 10+ software packages to FreeBSD ports in last 20 years, on principle "I need this, it is not in the ports yet, make new port for it". Typically it takes 2x-3x time to single source build, i.e. one day top, if it is not something super-complex like KDE and it is possible at all (i.e. not very Linux-specific when FreeBSD doesn't have required APIs). Modern build systems like npm and maven, which want to download and build all dependencies by themselves, are problem for this, I admit.

Eleison23 4y ago

[dead]

saghm 4y ago

Lately I've been coming around to the idea that AppImage is the best middle ground we have so far. Basically, it lets you provide static binary for people to download and use as-is if their repos don't have it available but then bundles in special flags starting with `--appimage-` for stuff like extracting the bundle libraries/assets into a directory structure that's the same for every AppImage. It seems like it's a step in the direction towards being able to automate making packages for various distros; It would be a tough design problem but really amazing if the format being expanded to be able to include source files so that each package manager could write their own plugins for converting the extracted AppImage into their own package format (appimage2deb, appimage2rpm, etc.). Maybe AppImage isn't the right basis for this sort of thing, but instead of trying to drive adoption of distro agnostic package managers which will face resistance from distro maintainers, I feel like the right solution would be something that provides for distros what LSP provided for editors and what LLVM provided for compiler authors. We're not lacking in package managers as a community, but we really could use a standard protocol or intermediate layer that _doesn't _ try to replace existing package managers but instead works with and relies upon them in a way that benefits everyone.

aprdm 4y ago
It’s worth noting that some big companies have something like what you describe. I was building packages for one and it’s basically reverse engineering however something is packed (e.g an RPM) and making it build/bundle in the way big corp operates. It’s a lot of busy work but we guaranteed that we had all dependencies in house and that the same package had the same layout of files across every OS
- saghm 4y ago
  I guess my hope is that rather than requiring a bunch of hardcoded boilerplate for each package management solution, we could come up with a reasonable set of primitives that they'd all need and then find a way to express them agnostically. The power of LLVM and LSP are that it's not just one entity producing all of the implementations, but that each side of the communication can contribute the stuff that's specific to their use case so that no one else needs to worry about those internal details. If I write a new programming language, all I need to do is implement a language server client, and then everyone can get plugins for pretty much any editor they want without needing to do a huge amount of work. It's possible something like this exists for package management right now, but my current impression is that the only products that try to provide something like this would not be as easily extensible to adding new distro package formats that might be invented but instead hardcode a few of the most common types (debian, rpm, etc.). The key part that seems to be missing is a standard for what the bits in the middle should look like; what's the package-level equivalent to LLVM IR or the LSP?

Ferret7446 4y ago

Hence the existence of flatpak and similar.

blacklion 4y ago

Author should not be packager. Distro users/maintainers should be packagers. Look at FreeBSD ports: there are more than 25K packages, most of them with latest upstream versions. How much of these packages are prepared by authors? Maybe, 1 in 1000 (I'm optimist, I know). NetBSD's pkgsrc is the same. It works. Authors better stick to traditional UNIX-style build system, which allows to pickup dependencies from local system without problems, and all distro-specific thing will be done by distro guys. I've ported 10+ software packages to FreeBSD ports in last 20 years, on principle "I need this, it is not in the ports yet, make new port for it". Typically it takes 2x-3x time to single source build, i.e. one day top, if it is not something super-complex like KDE and it is possible at all (i.e. not very Linux-specific when FreeBSD doesn't have required APIs). Modern build systems like npm and maven, which want to download and build all dependencies by themselves, are problem for this, I admit.