Dne 19.1.2014 23:37, Achilleas Pipinellis napsal(a): Historically, the idea of rubygem(foo) was that rubygem(foo) should correspond to require 'foo'. However, I am not sure that this was always true, since this was definitely underdocumented and guidelines stated that you should provide rubygem(%{gem_name}) instead. And the question is if we should support this or not. This might be useful for some gems, where the name of gem differs from the require-able file, for example rubygem-bcrypt-ruby comes to me mind. When we overhauled packaging guidelines during migration to Ruby 1.9.3, nobody remembered the history correctly and FPC decided to drop the note about rubygem(foo) require. With regards to comment [0], I would argue what is new or old syntax. They are both legal as long as they are satisfied IMO. Vít

Mamoru TASAKA wrote, at 01/20/2014 07:00 PM +9:00: 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. Regards, Mamoru

Vít Ondruch wrote, at 01/20/2014 07:54 PM +9:00: We can just start with what "gem" firstly does, I think it is a good start for adding automated provides/requires,i.e. check specification based dependency and automatically add provides/requires, almost the same as current gem2rpm does. rubygem(typical_file_you_should_require) seems much harder to implement, as far as I remember once python packages tried to do this, however it gave up. I think we can start with what may be implemented easier. Regards, Mamoru

Josef Stribny wrote, at 01/20/2014 11:38 PM +9:00: So use rubygem(foo) as I said before.

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&am... [2] https://bugzilla.redhat.com/show_bug.cgi?id=1070721 Dne 20.1.2014 11:54, Vít Ondruch napsal(a):

Dne 6.3.2014 16:40, Josef Stribny napsal(a): Of course there is a way [1], we just have yet no experience in what cases we will need it. Vít [1] https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering