Dependency generators

[Vít Ondruch]

Hi,

Following the discussion about format of requires/provides, I have
finally had time to implement them. Please take a look at [1].

Here are some random thoughts bout the generators and associated stuff:

* Currently, unless we cleanup all gems, the provides/requires in RPM
will be duplicated. One set will be provided by the generator while the
other will come from the .spec file. I opened ticket for RPM [2]
requesting post-filtering of requires/provides, but this is not gonna
save us. On the other hand, duplicated provides/requires should cause no
harm.

* gem2rpm should be updated and should not generate the Requires/Provides

* Packaging guidelines should be updated.

* We will need to learn how to filter/adjust the automatic
requires/provides in some cases. This should be probably documented in
guidelines as well.

* The generator is more or less taken from gem2rpm. Although in theory,
it could be dropped from its codebase, currently and for the foreseeable
future, it should stay there due to backward compatibility (and it could
be used for generating BR as well). This introduces code duplication.
Any thoughts how to get rid of it?

* It would be nice to have some test suite for the generators. It would
be probably good to thing about testsuite for our operating_system.rb as
well. Not sure how to organize it.

* Would it be useful to establish some "independent" upstream project
for all this stuff, something like javapackages-tools? We could have
chicken-egg issues later with bootstraping etc.

* What about ruby generators?

* Should we try to generate also some more precise provides, e.g. you
have to require 'bcrypt' from rubygem-bcrypt-ruby. In bundler, you have
to specify this explicitly, so this might be useful provide. How to
tackle this?


This is probably not exhaustive list of associated issues, so any
feedback is appreciated.


Vít



[1]
http://pkgs.fedoraproject.org/cgit/ruby.git/commit/?h=private-ruby-2.1&id=724ffdbb53749eb752ed8d30bc663e48a0738948
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1070721




Dne 20.1.2014 11:54, Vít Ondruch napsal(a):
> Dne 20.1.2014 11:11, Mamoru TASAKA napsal(a):
>> Mamoru TASAKA wrote, at 01/20/2014 07:00 PM +9:00:
>>> Achilleas Pipinellis wrote, at 01/20/2014 07:37 AM +9:00:
>>>> I know that both result to the same thing (if I remember correctly I
>>>> had
>>>> asked Vit about this in IRC), but I have forgotten their real
>>>> difference.
>>>>
>>>> My attention got caught by a comment Josef made in one of his reviews
>>>> [0], saying that rubygem-foo is the new syntax. If that's the case, I
>>>> would like to propose 2 changes:
>>>>
>>>> a) A reference in the wiki
>>>> b) An implementation for gem2rpm
>>>>
>>>> I guess b) could be fairly easy by changing the templates.
>>>>
>>>> By starting with these steps, there will be a push to use the new
>>>> syntax
>>>> from now on. What do you think?
>>>>
>>>> [0]: https://bugzilla.redhat.com/show_bug.cgi?id=979749#c2
>>>>
>>> Please use syntax other interpreters do:
>>> https://fedoraproject.org/wiki/Packaging:Perl?rd=Packaging/Perl#Perl_Requires_and_Provides
>>>
>>> https://fedoraproject.org/wiki/Packaging:PHP?rd=Packaging/PHP#Requires_and_Provides
>>>
>>> https://fedoraproject.org/wiki/Packaging:OCaml?rd=Packaging/OCaml#Requires_and_provides
>>>
>>>
>>> i.e. use rubygem(foo), not rubygem-foo.
>>>
>> Additional explanation:
>>
>> The idea here is that ideally like perl or so and pkgconfig(foo), etc,
>> this type of
>> dependency should be handled by rpmbuild _automatically_, i.e.
>> rpmbuild automatically
>> adds provides/requires rubygem(foo). Currently this is done by
>> gem2rpm, however if
>> this could be done on building rpmbuild side, it would be more
>> appreciated.
> It is doable, but we should still clarify what does it mean, i.e.
>
> 1) is it rubygem(%{gem_name}) or
> 2) should it be rubygem(typical_file_you_should_require), where for some
> gems, there might be more of these provides.
>
> I think it would be good to do it for F21, since I am going to propose
> guideline changes anyway. Hope I'll find some time to play with this.
>
>
> Vít
> _______________________________________________
> ruby-sig mailing list
> ruby-sig at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig