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-70514rpm-linter : FAILURE in 7m 26s container: Run rpmlint rpmlint /root/src/src.fedoraproject.org/rpms/ruby/*.rpmBut 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.rpmlintrc 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
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ ruby-sig mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
