Hacker News new | past | comments | ask | show | jobs | submit login

Gems only works because it's not only a package manager but also a monkey-patch for the Ruby interpreter which decides on the fly which files it should actually load. Nobody's going to be able to do that for every language runtime which has ever existed, so when someone screws up and releases an incompatible change, you have to give the new version's filesystem contents a different name, so dependencies have some way to specify which one they need. At that point it's clearer to rename the package as well.

I wouldn't expect any system to be able to make correct dependency checks (is this upgrade or uninstall safe?) for discovered files without being told what the dependencies are. If you have actual sysadmins (not devs who had root by mistake and misused it) who are smuggling files on a production box that aren't owned by a package (even one they created themselves), I hope they'll still be around to suffer the hell they're creating.




You don't have to do that for every language. Just support multiple versions in DPKG/RPM so that the languages who do support RubyGems-style loading can have multiple versions. Right now converting gems to DPKG/RPM is all manual work with no good way to automate it. DebGem tries to work around it by making a DEB that includes all existing versions but it's far from optimal.

> I wouldn't expect any system to be able to make correct dependency checks (is this upgrade or uninstall safe?) for discovered files without being told what the dependencies are.

So... tell it what the dependencies are?

Autoconf configure scripts can check for arbitrary things. It's just package managers that insist on only listening to their own databases.




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: