New Ruby packaging guidelines progress

[Mo Morsi]

On 04/02/2012 09:39 AM, Bohuslav Kabrda wrote:
> ----- Original Message -----
>> On 02/04/12 03:44 -0400, Bohuslav Kabrda wrote:
>>> Hi guys,
>>> here is a sumup of the last 2-hour FPC meeting, that me and Mo have
>>> attended:
>>> - Virtual provides are going to be killed completely (e.g. new
>>> packages will now depend on ruby-foo or rubygem-foo, rather than on
>>> ruby(foo) or rubygem(foo); no provides will be therefore necessary,
>>> as the package name is enough for this).
>> I could not make it to the meeting, but I have some issue with this.
>> There are efforts to maintain a stable API rubygems called slimgems
>> [1]. They forked rubygems at the 1.3.6 version.
>> It provides ruby(rubygems), and probably greater than 80% can replace
>>     Require: rubygems
>> with
>>     Require: ruby(rubygems)
>>
>> If this moved to ruby-rubygems, then none of the rubygem-foo would be
>> compatible with slimgems.
>>
>> Further, for noarch ruby libraries, how will this change accommodate
>> jruby?
>>
>>
>>
>> Take care,
>> vb
>>
>>
>> [1] https://github.com/slimgems/slimgems
>>
> I see your point. The problem is, that FPC wasn't willing to accept the way that we do the virtual Provides.
> What FPC says is, that they want rubygems to Provide both ruby(foo) and rubygem(foo), which I believed could make a great mess of things (I argued that if you have ruby-foo and rubygem-foo, then providing ruby(foo) would lead to uncertainty when you would use Requires: ruby(foo), but FPC has a different opinion on that...).
> It may still be possible to special-case this virtual Provide for rubygems (although Toshio would be strongly against it, I am afraid) - it was also possible to leave it for Ruby. I think that the whole Provides stuff should have remained the way that we had it until now. I am however unable to do anything more than trying to convince FPC, which hasn't lead to very good results up to now. If you want to open this topic again (or just want to ask for special-casing of slimgems), I'll be happy to support you, but perhaps you should first read what FPC says about that in this thread: http://lists.fedoraproject.org/pipermail/packaging/2012-March/008219.html
>
> Thanks!
>

Yes I'm also a fan of virtual provides. Though according to the FPC, our
case for them wasn't strong enough to allow us to keep them in the
guidelines.

That being said It sounds like slimgems might be that strong case we
were looking for. As Bohuslav mentioned, I would bring this up w/ the
packaging committee (the new guidelines are still open, the vote to
adopt them didn't happen at the last meeting). If we can keep hammering
on them, showing that the Fedora/Ruby community would like to continue
making using of virtual provides, then perhaps they will have a change
of heart.

  -Mo