Dne 09. 11. 23 v 19:09 jpro...@redhat.com napsal(a):
On 11/9/23 18:27, Vít Ondruch wrote:Generally up for this option for this situation. So far I have just adjusted the spec:Dne 07. 11. 23 v 12:56 jpro...@redhat.com napsal(a):Hi, On 11/1/23 17:13, Vít Ondruch wrote:JFTR, rubygem-rdoc has broken deps, resulting in not being able to install rubygem-rdoc and on EL* systems also the rubygems-devel by extension, this has to do with the `.dev` suffix that gets transformed in rubygem-io-console version.Hi, Here is yet another Ruby 3.3 snapshot, this time a1e24ab484: https://koji.fedoraproject.org/koji/taskinfo?taskID=108418495The respective changes are available in my PR. There is nothing particular what would catch my attention. Happy testing and thx for all the feedback and support.For fedora, I am doing the repoqueries and installs agains my new reverse dep rebuild Copr, with the SRPM from the koji build mentioned above (no content edits or adjustments): https://copr.fedorainfracloud.org/coprs/jackorp/ruby-3.3-fedora-november/The correct rdoc refuses to install: ~~~ $ dnf install rubygem-rdoc-6.5.0-183.fc40.noarchLast metadata expiration check: 0:09:16 ago on Tue Nov 7 11:44:02 2023.Error: Problem: conflicting requests- nothing provides rubygem(io-console) >= 0.6.1.dev needed by rubygem-rdoc-6.5.0-183.fc40.noarch from copr:copr.fedorainfracloud.org:jackorp:ruby-3.3-fedora-november(try to add '--skip-broken' to skip uninstallable packages) ~~~ I'll paste just relevant parts of rpm queries, to minimize noise: Fedora Rawhide: ~~~ $ dnf install rubygems-devel $ rpm -q --requires rubygems-devel rubygem(rdoc) >= 6.5.0 $ rpm -q rubygems-devel rubygems-devel-3.5.0.dev-183.fc40.noarch # rubygem-rdoc of this exact version is uninstallable $ dnf repoquery --requires "rubygem-rdoc-6.5.0-183.fc40.noarch" rubygem(io-console) >= 0.6.1.dev $ rpm -q --provides rubygem-io-console rubygem(io-console) = 0.6.1~dev rubygem-io-console = 0.6.1.dev-183.fc40 rubygem-io-console(x86-64) = 0.6.1.dev-183.fc40 ~~~Output for EL9 is more or less the same, just s/fc40/el9/, but it's more problematic there, as there isn't new enough version of rdoc, unlike in Fedora.Good spot. Yes, this is quite unfortunate. We have already faced similar issues, but that were typically just issues with upgrades, which were easy to neglect. But this would probably deserve some improvement.The issue is that wile it is easy to generate provides such as `rubygem(io-console) = 0.6.1~dev`, where the `~` replaces the period, because there is information about "pre-release", it is not that easy to generate the requires, because there is no such information that the dependency is pre-release. So I can see several options:1) Close our eyes and ignore the issue in a hope that stable release will not suffer the same~~~ %package -n rubygem-io-console # ... Other definitions for the package ... Provides: rubygem(io-console) = 0.6.1.dev ~~~
Yes, this will probably work, as long as Ruby is always installed on clean system. However, should there come io-console 0.6.1, the 0.6.1.dev might be kept installed I am afraid.
~~~ $ rpmdev-vercmp 0.6.1.dev 0.6.1 0.6.1.dev > 0.6.1 ~~~ But not sure. You can check and let me know ;)
2) Improve the requires generator. But there will be needed some heuristics, which might be error prone.This'd be preferred, or adjust the provides generator.I'd like to point out that I noticed there is already some smartistic on the Provider generator side: https://src.fedoraproject.org/rpms/ruby/blob/5fd12c42e7911fe5a07db3f92167983bd6e78008/f/rubygems.prov#_12 Could we just provide %{version}.dev AND %{version}~dev for such packages? We'd dodge doing error prone heuristics on Requirement generator and be IMO more correct in listing provides for pre-release gem versions.
It would be easy to generate the additional provide, but I am afraid it would be problematic as I have explained above.
3) Temporarily patch the tarball and drop the `.dev` suffix(es).3)a) If any such situation arises for actual release, adjust the requirement via already existing macros, to workaround this situation.
After all, I went for much simpler solution ;) https://src.fedoraproject.org/fork/vondruch/rpms/ruby/c/bb3a95723018cc892089b8bc9fd8f67f3eb94594The only remaining question is if the remaining `Recommends: rubygem(io-console)` should be treated the same way. Being soft dependencies, I believe that the `Requires` wins and the `Recommends` becomes no op. Not really sure if the version might help updating io-console at some point or it might actually hinder the installation, because e.g. there actually might have been io-console 0.6.1.dev installed already.
The more I think about it, the more I am in favor of removing the versions from io-console dependencies altogether.
Vít
But I find point 3 overall to not be that great (I prefer option 1 for WIP pre-release PRs, least amount of work IMO).JarekNot sure if (3) is feasible, but at the first look, this looks to be like the least effort.Vít_______________________________________________ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.orgFedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelinesList Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- _______________________________________________ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org 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/ruby-sig@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
