13 ms·
> Creating proper platform-specific packages is a mad undertaking, requiring huge amounts of manpower to setup and to maintain. Of course you are right, and I
by davidroetzel 13y ago
> Creating proper platform-specific packages is a mad undertaking, requiring huge amounts of manpower to setup and to maintain.
Of course you are right, and I am well aware of this. After all, that is the reason it has not been done before.
Still, a crazy amount of effort went into creating and maintaining rvm, rbenv and the myriad of other tools we now have. I cannot help but wonder where we would stand now had all of this instead been directed towards great packaging.
> You'd end up with at least 100 different packages, and you'll have to test each one of them. That's going to cost much more than a one-off campaign of $50000.
I am not quite so pessimistic. What I am daydreaming about would involve the distributions and their package maintainers. They already ship ruby right now. The packages are just not in optimal shape and oftentimes not up to date.
But one can surely build on the foundation already laid out by the distributions and work with them to hand off some of the work.
Still, I know this would be a herculean task. And not only a technical challenge, but a social one as well.
- mpapis 13y agosystem packages and maintainers in current day are not used to support mixing multiple software with an easy separation like RVM does, they put everything in one prefix like /usr and change only application suffix, it works well with alternatives-update - but it’s static switching of ruby, what developers need is runtime switching and clear separation of libraries per language, the lack of clean separation also is bad when deploying servers that run multiple versions of given language (not limiting to ruby) also check the update with schedule - https://www.bountysource.com/fundraisers/489-rvm-2-0 https://www.bountysource.com/fundraisers/489-rvm-2-0 - "2 months: Work on building packages using RVM 2 (so it deprecates itself)"