[csw-maintainers] newpkgs rb18_libxml_1_1_4

[Philip Brown]

On Thu, Apr 7, 2011 at 12:23 PM, Ben Walton <bwalton at opencsw.org> 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.