Alex Young wrote: > It sounds like the best practice *right now*, then, is: > > # apt-get install ruby rubygems All good and fine. > # gem install rails I haven't read through the current instantiation but in the previous one this would overwrite dpkg installed files in /usr. That scares me! Does it still operate that way? It needs root and therefore I assume it does or it wouldn't need root to install. Group 'staff' would otherwise be sufficient if it were in the /usr/local tree. And it also has the same disadvantages of using rvm in the problems of dealing with upstream version dependency problems. Might as well use rvm then. Having a packaged set would enable creating a consistent layer of packages that have known compatible versions. This is my biggest desire since it allows deploying to a new instance one of installing deb packages. But needing to use gems means possible differences from one install to another. Or needing to specify each and every gem by gem and version in order to freeze on a known contour of working gem versions. And it means that each user (me!) needing to manage that list carefully over the site lifetime. > Even when all the requirements for rails 3 get into > wheezy-backports, I'd still go for this because we're not *that* far > off rails 4, and a gem installed rails will have an easier upgrade > path, for my money. Again I think that path isn't that much different from using rvm. I would rather have a system package path for install and upgrade. However rvm is here today but a system package path isn't complete yet. Until it is then the discussions are a little one sided. But getting more even! :-) Bob
Attachment:
signature.asc
Description: Digital signature