On Thu, Apr 7, 2011 at 12:23 PM, Ben Walton <[email protected]> wrote: > Excerpts from Philip Brown's message of Thu Apr 07 14:20:33 -0400 2011: >... > >> seems like we should have documentation for, and agreement on, this >> new standard, before releasing stuff like that. > > http://wiki.opencsw.org/ruby-dublin
Thanks for the ref... That page is very short. I would suggest that in a complex topic such as this, it is best for such writeups to have as much "why" details, as "what". Did you guys compare to what debian is doing in this space? There are some interesting comments on that, at http://stackoverflow.com/questions/2846804/whats-the-deal-with-rubygems-on-debian-its-different-and-strange > The rb_ standard was good and this is the logical extension of the > prefix for a world where a gem will be for 1.8 or 1.9. > > The new naming scheme also allows for multiple gem versions to live on > the system at once (the same capability that gem offers if you install > manually). This eases the update burden over time as we don't need to > provide a transition path from one set of gems (think rails) to > another, where the upstream community has made incompatible changes. > It's basically the same idea that drives our library splitting. I think it's worth noticing, that not even debian, with its "lets try to cater to everything, and everyone", attempts to support rubygems for two completely different versions of ruby. This suggests to me, that this is potentially Not A Good Idea. It may be better to simply declare, "Right now, we support version [X] of ruby+rubygems. If you want to go your own way,with a different version /combination of ruby+rubygems... we suggest you use rubygems, AS rubygems: ie: as its own package management and download system. [and we might optionally provide some kind of convenience package for that]" the comment on the URL I reference above, has this to say on the topic: "In general, you should avoid mixing package managers. Either use RubyGems for everything (in which case it is best to install RubyGems from source instead of using the Debian package) or use APT for everything, in which case you might be interested in DebGem, a service by the Phusion guys (makers of Ruby Enterprise Edition and Phusion Passenger) which provides Debian and Ubuntu packages for pretty much all Gems." This would match with our perl/cpan strategy. we dont attempt to support multiple versions of cpan, with multiple versions of perl. For any particular cpan module, we have ONE version of it, for our ONE version of officially suported perl. _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
