Dne 22. 03. 21 v 11:44 Jun Aruga napsal(a):
>>> ### 5.
>>>
>>> ```
>>> ruby-default-gems.noarch: W: obsolete-not-provided rubygem-did_you_mean
>>> If a package is obsoleted by a compatible replacement, the obsoleted package
>>> should also be provided in order to not cause unnecessary dependency
>>> breakage.
>>> If the obsoleting package is not a compatible replacement for the old one,
>>> leave out the Provides.
>>>
>>> ruby-default-gems.noarch: W: obsolete-not-provided rubygem-openssl
>>> If a package is obsoleted by a compatible replacement, the obsoleted package
>>> should also be provided in order to not cause unnecessary dependency
>>> breakage.
>>> If the obsoleting package is not a compatible replacement for the old one,
>>> leave out the Provides.
>>>
>>> ruby-default-gems.noarch: W: obsolete-not-provided rubygem-racc
>>> If a package is obsoleted by a compatible replacement, the obsoleted package
>>> should also be provided in order to not cause unnecessary dependency
>>> breakage.
>>> If the obsoleting package is not a compatible replacement for the old one,
>>> leave out the Provides.
>>> ```
>> It think this should not be a warning, but a mere INFO. Note the 'IF'.
>>
>>> =>
>>> The Provides line needs for the Obsolete line.
>> I don't think we want to create Provides for those, as those are
"Default" gems.
>
> The Obsoletes/Provides are always tricky. I think these are fine as they
> are.
Could you explain more about the Obsoletes/Provides are always tricky?
Maybe I do not understand "Provides" syntax well.
Do you know a helpful web page explaining it?
1) It is always up to debate, what `compatible replacement` actually
means. `ruby-default-gems` certainly provides did_you_mean, but how
compatible it is? The original independent gem had definitely some
idiosyncrasies, while the bundle gem has different set.
2) If you start with `Provides`, then the question is when to stop
providing them. If something depends on them, the dependencies won't be
fixed any time before the `Provides` is removed (or the chances are just
slim).
3) After all, the message is in this case is clear, get back closer to
the upstream. People should not bother with rubygem-did_you_mean
anymore. This should be forgotten.
>>> ## rpms/ruby CI to add rpmlint test.
>>>
>>> Can we check the rpmlint issues on an early timing: pull-request and push?
>>> I think adding the rpmlint check ro rpm/ruby CI is a possible way
>>> related to this ticket.
>> Yes, I agree we could add this for the CI (functional). I'm not sure some
generic checks aren't considered already for all PRs- I'll inquire abou it and
follow up with you on IRC.
>>
>>>
https://src.fedoraproject.org/rpms/ruby/pull-request/67
>>> Shall we add it after the PR #67 will be merged?
>
> The Zuul is running rpmlint on PR. You can check the PR you've
> referenced above.
That's good news. I can see the running rpmlint there.
https://src.fedoraproject.org/rpms/ruby/pull-request/78#comment-70514
> rpm-linter : FAILURE in 7m 26s
> container: Run rpmlint
>
> rpmlint /root/src/src.fedoraproject.org/rpms/ruby/*.rpm
But this rpmlint command is not enough. The rpmlint for the
`ruby.spec` should be added like this.
Where can we report this issue?
@fbo was always helpful, e.g. here:
https://src.fedoraproject.org/rpms/ruby/pull-request/70#comment-60863
```
$ rpmlint /root/src/src.fedoraproject.org/rpms/ruby/*.rpm /path/to/*.spec
```
And I love to see all the SUCCESS results as a default. Because the
default green status makes us notice new issues easily.
I think it's time to create ruby.rpmlintrc.
Seeing the example of python3.9 package, it seems that we can
intentionally ignore the false positive errors/warnings for a specific
file
https://src.fedoraproject.org/rpms/python3.9/blob/rawhide/f/python3.9.rpm...
https://fedoraproject.org/wiki/Taskotron/Tasks/dist.rpmlint
What do you think?
This is always double edge sword. The best would be if rpmlint does not
report false positives, otherwise it will be always just informative.
Vít