On Mon, Mar 22, 2021 at 12:31 PM Vít Ondruch <vondruch(a)redhat.com> wrote:
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.
OK. That makes sense. Maybe the rpmlint warnings should be suppressed by us.
>>>> ## 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
OK. I am asking @fbo to fix this issue on the following comment.
https://src.fedoraproject.org/rpms/ruby/pull-request/78#comment-70600
> ```
> $ 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.
We can see the informative result even when there is a `ruby.rpmlintrc` file.
The `ruby.rpmlintrc` file does not harm our current manual operation
when someone wants to see the original informative result.
```
$ cat ruby.rpmlintrc
addFilter(r'^ruby.spec:\d+: E: use-of-RPM_SOURCE_DIR$')
```
The rpmlint without `--file` option shows the original information.
```
$ rpmlint ruby.spec
ruby.spec:20: E: use-of-RPM_SOURCE_DIR
ruby.spec:231: W: unversioned-explicit-provides bundled(ccan-build_assert)
ruby.spec:232: W: unversioned-explicit-provides bundled(ccan-check_type)
ruby.spec:233: W: unversioned-explicit-provides bundled(ccan-container_of)
ruby.spec:234: W: unversioned-explicit-provides bundled(ccan-list)
0 packages and 1 specfiles checked; 1 errors, 4 warnings.
```
When using the `--file` option, we can suppress the false positive
intentionally by specifying the message.
```
$ rpmlint --file ruby.rpmlintrc ruby.spec
ruby.spec:231: W: unversioned-explicit-provides bundled(ccan-build_assert)
ruby.spec:232: W: unversioned-explicit-provides bundled(ccan-check_type)
ruby.spec:233: W: unversioned-explicit-provides bundled(ccan-container_of)
ruby.spec:234: W: unversioned-explicit-provides bundled(ccan-list)
0 packages and 1 specfiles checked; 0 errors, 4 warnings.
```
I guess you do not check the informative result by the rpmlint when
pushing your commit by yourself, right?
If the informative result is not checked, it is not useful.
--
Jun | He - His - Him