3 ms·

RPM "solved" it too. I hate package management so much. I hate installing unnecessary cruft to get a box with what I want on it. It makes me pine for tarballs

RPM "solved" it too. I hate package management so much. I hate installing unnecessary cruft to get a box with what I want on it. It makes me pine for tarballs built on boxes w/ compilers installed and deployed directly onto the filesystem of the target machines. Edit: I'd love to see package management abstracted to a set of interfaces so I could use my OS package manager for all of the bespoke package management that every programming language seems hell-bent on re-implementing.

dzr0001 9mo ago
I think there's a fundamental difference between programming language repos and package repositories like the official RPM, deb, and ports trees. These (typically) operating system repos have oversight and are tested to work within a set of versions. Repositories with public contribution and publishing don't have any compatibility guarantees, so the cruft described in the article must be kept indefinitely. Unfortunately, I don't think abstracting those repositories to work within the OS package ecosystem would solve that problem and I suspect the package manager SAT solvers would have a hard time calculating dependencies.
- EvanAnderson 9mo ago
  I agree re: the fundamental difference when it comes to compiled languages. I wrote rashly and out of frustration without thinking about it too deeply. re: interpreted languages, though, I think it's still a shit show. I don't want to run "composer" or "npm" or whatever the Ruby and Python equivalents are on my production environment. I just want packages analogous to binaries that I can cleanly deploy / remove with OS package management functionality.
themafia 9mo ago
> It makes me pine for tarballs built on boxes w/ compilers installed and deployed directly onto the filesystem of the target machines. You're effectively describing Gentoo. Just a personal opinion but it's awesome.
imtringued 9mo ago
OS package managers are the equivalent of a massive monorepo. You have to ask them to let you in and they have many reasons to refuse you and yet you have to do your job anyway.

dzr0001 9mo ago

I think there's a fundamental difference between programming language repos and package repositories like the official RPM, deb, and ports trees. These (typically) operating system repos have oversight and are tested to work within a set of versions. Repositories with public contribution and publishing don't have any compatibility guarantees, so the cruft described in the article must be kept indefinitely. Unfortunately, I don't think abstracting those repositories to work within the OS package ecosystem would solve that problem and I suspect the package manager SAT solvers would have a hard time calculating dependencies.

EvanAnderson 9mo ago
I agree re: the fundamental difference when it comes to compiled languages. I wrote rashly and out of frustration without thinking about it too deeply. re: interpreted languages, though, I think it's still a shit show. I don't want to run "composer" or "npm" or whatever the Ruby and Python equivalents are on my production environment. I just want packages analogous to binaries that I can cleanly deploy / remove with OS package management functionality.

themafia 9mo ago

> It makes me pine for tarballs built on boxes w/ compilers installed and deployed directly onto the filesystem of the target machines. You're effectively describing Gentoo. Just a personal opinion but it's awesome.

imtringued 9mo ago

OS package managers are the equivalent of a massive monorepo. You have to ask them to let you in and they have many reasons to refuse you and yet you have to do your job anyway.