On Mon, Mar 22, 2021 at 12:31 PM Vít Ondruch <[email protected]> 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.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. 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 _______________________________________________ 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
