Lucas Nussbaum wrote:
> On 19/03/10 at 02:49 +0900, Aldric Giacomoni wrote:
>> tree for gems - you can essentially get the gems installed and supported 
>> by your distribution. It is of course far from perfect, but they're 
>> doing a fine job of it.
>> Then again, they have just recently started handling license acceptance 
>> for things like Java, VMWare and such, so Debian is eons ahead of them 
>> in that regard -- which is in fact at the core of our current debate.
> 
> I think that rubygems and emerge and actually quite similar, which
> probably explains why they work together well. Rubygems is a great tool
> for developers who want to get the latest cutting edge software.
> However, at some point, applications are transferred from developers to
> sysadmins, and "cutting edge" isn't really a good selling point.
>
> 
> I think that approaches that aim at getting rubygems and apt-get to
> cooperate are just wrong. Both rubygems and apt-get have good reasons to
> exist, but they don't solve the same problem.  Instead, we should try to
> develop a set of good practices that make it easier to convert a ruby
> library into a "normal" Deb or RPM package. Much progress has already
> been done lately, and the last libraries I've packaged didn't use
> "require 'rubygems'" except in the test suite, so they did not require
> any patching.
>
Apt-get does not really handle slotting in the way portage does, and I 
think that's what you are thinking about when you say that rubygems and 
portage work the same way.
Rubygems isn't meant for what you describe, but I agree that it helps 
that behavior. Its purpose is to manage different versions of gems 
because it understands that purposes and APIs can change.
Did we mention that gems can be released under whatever license the 
owner wants? What a nightmare for Debian's apt-get system...
I'm glad to hear that it's becoming easier to integrate libs into 
apt-get.

Someone suggested, earlier, that we add ruby to a different branch of 
the debian sources. How about creating a separate tree for the gems, 
where the updating can be done more quickly than on the regular tree? Is 
that idea a no-go because of Debian policies (of which I am blissfully 
ignorance) ?

> 
>> Is it possible to add a message of some sort to the 
>> pre-install apt-get warning when installing Ruby, to explain the 
>> different Ruby packages?
> 
> I have kind-of done that a few hours ago.
> 
> Now:
> # apt-get install ruby
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> The following extra packages will be installed:
>   libruby1.8 ruby1.8
> Suggested packages:
>   irb rdoc ri libopenssl-ruby ruby-dev ruby1.8-examples rdoc1.8 ri1.8
> The following NEW packages will be installed:
>   libruby1.8 ruby ruby1.8
> 0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
> Need to get 2060kB/2082kB of archives.
> After this operation, 6980kB of additional disk space will be used.
> 
> (See the list of Suggested packages)
> 
> It's not much, but still a slight improvement, which should probably
> have been done before.

That's great - I think it's probably the best way to start. The rest 
will come down to meetings and long discussions about policies.. :)
Now if only users would _read_ ! :p

-- Aldric Giacomoni
What is the source of conflict?
-- 
Posted via http://www.ruby-forum.com/.