Hacker News new | ask | show | jobs
by vetinari 3595 days ago
You might have the right to install packages, but that may not solve your problem, that the application may require different version than available in the repo.

The classical case is Ruby + Rails + Passenger + CentOS. While there is SCL with any Ruby and Rails version you might want, that does not mean, that the Passenger package will work with it :(.
1 comments
cookiecaper 3595 days ago
Yeah, if you can install packages, then you can run the RVM installation script and install the right version of Ruby. In fact, you don't even need admin privileges if you use RVM.
link
vetinari 3595 days ago
That will get you off package system for the entire stack and now the maintenance of the whole circus is up to you. Which is exactly what I'm trying to get away from.
link
cookiecaper 3594 days ago
I do dislike individual language package managers and ecosystems for this reason, but I think it's gotta be accepted at this point. Practically every language has their own package repo and versioning apparatus now. Ruby has RVM, Node.js has NVM, Python has PyPi/venv, etc. Most projects expect their users to deploy with these and include things like Gemfiles to define dependencies. That usually means if you insist on using the upstream packages provided by the distribution, you're going to have to install them manually and have a bunch of extra headaches to worry about anyway (to be honest, most custom applications are really difficult to get running using only distro-packaged Ruby or Python libs).
link
vetinari 3594 days ago
The individual language package managers are very nice for development, as you may have any package version you want, and also for non-linux users, where there may be no native package management at all. For operations, however, they suck mightly (that's terminus technicus).

I quite like the SCL [1]. It solves the problem, that you might need different version of node/python/ruby/rails/php/whatever, than is packaged with the OS release of your choice. It has the software nicely packaged and maintained. Now getting third party packages to work with that, that's the problem. Passenger rpm [2] requires system-provided ruby, not just any ruby... I will survive that that App X wants Gem Y installed by rubygem. I won't like it, but it is workable and makes maintenance/updates slightly more difficutlt. But I will not put unpackaged module into Apache config.

[1] https://www.softwarecollections.org/

[2] https://www.phusionpassenger.com/library/install/apache/inst...

link