4 ms·

[Disclaimer: I'm not a Ruby developer, but have developed in plenty of languages, as well as being a sysadmin for a fair while] IME, separate package-managemen

[Disclaimer: I'm not a Ruby developer, but have developed in plenty of languages, as well as being a sysadmin for a fair while] IME, separate package-management for each and every language is more painful than the problem he is describing. Rubygems, CPAN, whatever other languages use. As soon as you install things outside of the distro package-manager, it has no idea what is going on with those packages and so continues to think that they aren't installed. If there was a way to get the package-managers for language libraries and the distro to play together nicely and work for dependencies etc then this would be OK, but as it is it's a bit of a sysadmin nightmare. Edit: I thought that installing distro-supplied packages into /usr/local was against the FHS?

davidw 16y ago
> way to get the package-managers for language libraries and the distro to play together nicely and work for dependencies etc Yes, hacking the language's package manager to talk to the distribution package manager is probably the only way to really go about solving the problem in an elegant way, and even that is not without its pain points.
- legooolas 16y ago
  > pain points Absolutely, but this problem has been around for a long time, and fighting with distributions on how to get it to work won't help anyone. Of course, it also means that if you install a buggy version of a library from, say, CPAN then you could break distro-supplied packages... I guess it depends on which you value more: distributor-provided testing or being able to install out-of-band packages onto your distribution more easily and with proper dependencies.