----- 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!
--
Regards,
Bohuslav "Slavek" Kabrda.