3 ms·

Usually, yes, it appears. Maintainers of projects are generally pretty invested in getting their software into popular distros... and so they tend to follow the

Usually, yes, it appears. Maintainers of projects are generally pretty invested in getting their software into popular distros... and so they tend to follow the patterns that would allow that. (I mean, stuff like 'where do I put the binaries' is still often configured in Arch and other distros, so we're talking about stuff outside of that kind of thing. Most packages aren't complicated enough to require anything outside of simple configure flags.)

josephg 6y ago
I wish there were more standards & conventions here. It seems silly that every package needs to be manually packaged for Debian/red hat/arch/etc, FreeBSD, homebrew, and maybe Cygwin/whatever people use now. That’s a whole lot of work, often for every new version of the program! And all that work could vanish if there was a standard bundler. I think modern package managers for programming languages show us the right approach here. A cargo binary crate can be built on any platform that rust supports, it knows it’s dependencies and the compiler flags are passed in in a consistent way. I could imagine cargo having a 1 button “publish crate to dpkg/homebrew/ etc etc” button. Or alternately, I could imagine Debian allowing crates.io to exist as part of the package namespace. Then you could “apt install crate/foo” and the “foo” package author wouldn’t have to think about dpkg at all. (Maybe this already exists? It would be a sweet way to use the ppa system.)
- rrdharan 6y ago
  > And all that work could vanish if there was a standard bundler. The same balance of forces that mandate all of that toilsome work are exactly what would prevent any standard bundler from succeeding. You can follow https://utcc.utoronto.ca/~cks/space/blog/linux/SnapsFlatpaksReasonsWhy https://utcc.utoronto.ca/~cks/space/blog/linux/SnapsFlatpaks... and https://www.techrepublic.com/article/why-snap-and-flatpak-are-so-important-to-linux/ https://www.techrepublic.com/article/why-snap-and-flatpak-ar... and various related discussions around this and eventually I am confident you will conclude that while things may change (today there's docker in the mix as well, tomorrow there will be something else), the one-true-packaging-solution will never be invented. There are simply far too many fundamentally conflicting interests to ever prevent that level of standardization. What you see now is more or less what you will always get. Or, perhaps, we'll see something worse (i.e. only fully locked down computing devices, only app stores with no sideloading capabilities, various other dystopian outcomes). I'm pretty sure we're not going to see something better though; we've had plenty of time...

josephg 6y ago

I wish there were more standards & conventions here. It seems silly that every package needs to be manually packaged for Debian/red hat/arch/etc, FreeBSD, homebrew, and maybe Cygwin/whatever people use now. That’s a whole lot of work, often for every new version of the program! And all that work could vanish if there was a standard bundler. I think modern package managers for programming languages show us the right approach here. A cargo binary crate can be built on any platform that rust supports, it knows it’s dependencies and the compiler flags are passed in in a consistent way. I could imagine cargo having a 1 button “publish crate to dpkg/homebrew/ etc etc” button. Or alternately, I could imagine Debian allowing crates.io to exist as part of the package namespace. Then you could “apt install crate/foo” and the “foo” package author wouldn’t have to think about dpkg at all. (Maybe this already exists? It would be a sweet way to use the ppa system.)

rrdharan 6y ago
> And all that work could vanish if there was a standard bundler. The same balance of forces that mandate all of that toilsome work are exactly what would prevent any standard bundler from succeeding. You can follow https://utcc.utoronto.ca/~cks/space/blog/linux/SnapsFlatpaksReasonsWhy https://utcc.utoronto.ca/~cks/space/blog/linux/SnapsFlatpaks... and https://www.techrepublic.com/article/why-snap-and-flatpak-are-so-important-to-linux/ https://www.techrepublic.com/article/why-snap-and-flatpak-ar... and various related discussions around this and eventually I am confident you will conclude that while things may change (today there's docker in the mix as well, tomorrow there will be something else), the one-true-packaging-solution will never be invented. There are simply far too many fundamentally conflicting interests to ever prevent that level of standardization. What you see now is more or less what you will always get. Or, perhaps, we'll see something worse (i.e. only fully locked down computing devices, only app stores with no sideloading capabilities, various other dystopian outcomes). I'm pretty sure we're not going to see something better though; we've had plenty of time...