Provides: rubygem(name) automation

[Mo Morsi]

On 04/27/2011 05:02 AM, Vít Ondruch wrote:

>>
>> One additional question I had is how easy it would be to override the
>> dependency generator. Lets say there is a mistake in the generator or a
>> use case that it does not work for and/or generated incorrect
>> dependencies for, will ruby packagers have to wait until that is
>> resolved to submit their packages. Will explicit dependencies in the
>> spec override the dependency checker?
>>
> 
> In my understanding, there will be always both dependencies listed. One 
> set of dependencies will be generated automatically by some dependency 
> generator and there will second set of dependencies entered explicitly 
> in .spec file.
> 


OK this sounds good provided we can override the automatically generated
dependency in the specfile.

For example if the dependency generator says we need rubygem-i18n w/ an
unqualified version, but I know that due to some bug it won't work w/
i18n before version x.y.z, I should be able to add that to the spec and
everything should work dandy.

Another example which might be a little tricker to solve would be if a
gem lists a dependency that we can't ship in Fedora, but isn't strictly
necessary to the functionality of that gem (an additional plugin or
feature for example). If the dependency generator picks this up, we'll
need a way to remove the dependency manually.

When the dependency generator is run will play into this, if we can
patch the sources before the dependencies are generated (though this is
unlikely for BuildRequires), we can remove anything before its passed
into the dependency generator.

Of course, I can't imagine that these issues are Ruby specific, so
perhaps this has already been thought of?

  -Mo