Fwd: Re: Provides: rubygem(name) automation

[Mo Morsi]

On 04/27/2011 06:42 AM, Vít Ondruch wrote:
>  I am forwarding response from Alex.
>> > 
>> > 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?
> 
> * You can disable the dependency generator entirely. See 
> http://rpm.org/wiki/PackagerDocs/DependencyGenerator


Ya I read through this but did not see the bit about disabling the
generators, did I miss it?


> * You can add additional provides manually and let the automatically generated 
> provides just stay as is. It's not a problem if your manual provide is the 
> same as the automatically generated one.
> You would not have to wait because everything you put in the spec file manually 
> will simply be there no matter what the dependency generator has done.
> 

Tru, though I'm little concerned about dependencies represented in both
the automatically generated list and manually in the spec file, eg where
the dependency generator thinks its one thing but the packager knows its
something else. (see the examples in my previous email).

That being said, from what I've seen I think the majority of cases
should work with this and those that don't aren't are good candidates
for upstream bug reports. IMO I agree this should save some packaging
time overall.


>> 
>> 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.
> 
> That's not exactly true. Ideally after reaching critical mass with automated 
> provides/requires generated you will not need to add anything manually in most 
> cases unless there is some obscure case.
> 

Agreed, though just want to make sure we can handle those obscure cases.

  -Mo