[Rpm-maint] %setup for RubyGems

[Vít Ondruch]

Dne 1.11.2016 v 10:26 Pascal Terjan napsal(a):
> On 1 November 2016 at 09:01, Vít Ondruch <vondruch at redhat.com> wrote:
>>
>> Dne 1.11.2016 v 09:08 Pascal Terjan napsal(a):
>>> On 1 November 2016 at 07:53, Vít Ondruch <vondruch at redhat.com> wrote:
>>>> Dne 1.11.2016 v 00:04 Pascal Terjan napsal(a):
>>>>> One big problem with having the gemspec in the parent directory is
>>>>> that we can't easily apply patches to it.
>>>> You are right. Never thought about it. But I would not call it "big"
>>>> problem ;)
>>> Well not being able to use %autopatch / %autosetup / ... is annoying
>>>
>>>>> This is a problem for about a dozen packages with invalid gemspec
>>>>> (duplicate dependencies, empty author, ...).
>>>> Do you have some examples please?
>>> 2 random examples:
>>>
>>> + /usr/bin/gem build ../ruby-openid-apps-discovery-1.2.0.gemspec
>>> WARNING:  See http://guides.rubygems.org/specification-reference/ for help
>>> ERROR:  While executing gem ... (Gem::InvalidSpecificationException)
>>>     authors may not be empty
>>>
>>> + /usr/bin/gem build ../journey-1.0.4.gemspec
>>> WARNING:  licenses is empty, but is recommended.  Use a license
>>> abbreviation from:
>>> http://opensource.org/licenses/alphabetical
>>> WARNING:  open-ended dependency on racc (>= 1.4.6, development) is not
>>> recommended
>>>   if racc is semantically versioned, use:
>>>     add_development_dependency 'racc', '~> 1.4', '>= 1.4.6'
>>> WARNING:  open-ended dependency on json (>= 0, development) is not recommended
>>>   if json is semantically versioned, use:
>>>     add_development_dependency 'json', '~> 0'
>>> WARNING:  See http://guides.rubygems.org/specification-reference/ for help
>>> ERROR:  While executing gem ... (Gem::InvalidSpecificationException)
>>>     duplicate dependency on rdoc (~> 3.10, development), (~> 3.11) use:
>>>     add_runtime_dependency 'rdoc', '~> 3.10', '~> 3.11'
>>> error: Bad exit status from
>>> /tmp/ruby/ruby-journey/BUILDROOT/rpm-tmp.umx65z (%build)
>>>
>>> We can probably kill some of those packages as they seem dead upstream
>>>
>>>> Do I understand correctly that you actually take some gem, do "gem spec
>>>> --ruby" and you can't rebuild such gem with "gem build"?
>>>>
>>> Yes
>>>
>>> There are also a few other cases when we have patches, mostly to allow
>>> newer versions of some dependencies
>> So let me make a few remarks.
>>
>> * The patches won't be applicable not just because the .gemspec is
>> generated in parent directory, but because they are versioned now. Hence
>> the patch needs changes with version updates.
>>
>> * But anyway, I don't think patching the generated .gemspec is good
>> idea. You used to patch the .gemspec, because you used mixture of
>> upstream .gemspec with generated .gemspec. I think it is reasonably OK,
>> to patch the upstream .gemspec (but then you still have to fight with
>> things such as "git ls-files"), but I don't think it is good idea to
>> patch the generated .gemspec, since even minor changes in RubyGems might
>> change the formatting. For example if I am not mistaken, RubyGems in
>> Ruby 2.4 apply #freeze method on every string, which will render your
>> current patches unusable.
> True that's a problem
>
>> * The two packages you pointed out are really obsolete. Journey was
>> subsumed into Rails long time ago, while the ruby-openid-apps-discovery
>> is dead upstream. I don't think you will encounter issues you described
>> with any up-2-date gem.
> Yes, until they change something in gem which again breaks more recent ones
>
> In the previous example, ruby-openid-apps-discovery had last commit in
> July 2012, rubygems 2.0 which broke it was released in February 2013.
> At that time we had to patch a larger number of packages.
>
> I can imagine a number of recent gems breaking again in the future
> that we would need to patch.

I agree, but this should be RubyGems upstream discussion IMO, because
they are breaking backward compatibility not just to us.

>
>> * Yes, changing dependencies is valid use case. I typically preferred to
>> use sed for this purpose, since it is more flexible then applying
>> patches. But recently, I introduced macros for this purpose [1, 2] into
>> Fedora. I believe they are superior to any other approach.
> Yes I had considered that but never took the time to write them, I may
> steal yours :)

Feel free to steal it

BTW speaking of patching gem, we once developed gem-patch RubyGems plugin:

https://rubygems.org/gems/gem-patch

May be it might come handy one day


Vít