Re: Conflicting racc
Dne 21. 12. 23 v 1:23 Mamoru TASAKA napsal(a): Mamoru TASAKA wrote on 2023/12/21 9:04: Vít Ondruch wrote on 2023/12/21 0:45: I have just hit this issue: ~~~ Error: Transaction test error: file /usr/lib64/gems/ruby/racc-1.7.3/racc/cparse.so from install of ruby-bundled-gems-3.3.0~20231219git8e6f63df47-184.fc40.x86_64 conflicts with file from package rubygem-racc-1.7.3-200.fc40.x86_64 file /usr/share/gems/specifications/racc-1.7.3.gemspec from install of ruby-bundled-gems-3.3.0~20231219git8e6f63df47-184.fc40.x86_64 conflicts with file from package rubygem-racc-1.7.3-200.fc40.x86_64 ~~~ The problem here is that racc is now bundled gem, where previously it was default gem, therefore there is now this conflict. How are we going to solve this? There are several options: 1) Make rubygem-racc subpackage of Ruby. We used to do this [1], but with default gem, the situation was different. 2) Install default gems / our system gems into dedicated directory, where they won't conflict. I was already proposing it elsewhere to explore the `gem install --vendor` or I have proposed upstream to have dedicated directories for default / bundled gems. Is it the right time to do this? 3) Drop the independent rubygem-racc Actually I am not sure how sever this situation is, because I have explicitly installed rubygem-racc prior the ruby-default-gems get chance to be installed. So maybe we still have some time to thing about it. Thoughts? Vít [1] https://src.fedoraproject.org/rpms/ruby/c/baf046a6a4d17fa309c9d20fa3db949f6c24aacf Because new version of racc (independent) gem may be released during ruby 3.3 stage (actually racc version 1.7.0 was released 2023/Jun) and when that happens, racc bundled in ruby 3.3 won't be updated, to make it possible to update rubygem-racc version, I don't think 3) is what we want (at least I don't want 3)) . I think 1) is the "simplest" way in that this is the least likely way where some misbehavior can happen. 2) can be the option, but I think we can defer to this for ruby 3.4. Or... 4) Make ruby-default-gems have "Obsoletes: rubygem-racc < 1.7.4" ? Thank you for pointing out this scenario. I think I had it somewhere back in my mind, but it have not bubbled up on the surface writing this email. So this way, unless I am wrong: * when rubygem-racc-1.7.3-200.fc40 is firstly installed, rubygem-default-gems should Obsolete this independent rubygem-racc because of this. * when independent rubygem-racc version is updated, this Obsoletes no longer in effect, but as version differs between independent rubygem-racc and bundled one, so there should be no file conflict, perhaps? * Then when racc version in ruby-default-gems is updated, we can again have "Obsoletes: rubygem-racc < 1.7.5" in ruby-default-gems. At least, for current situation, 4) (i.e. use Obsoletes instead of dropping) should work. Anyway, thank you for pointing this out. After second thought, maybe some bugfix backport can happen even in rubygem-racc 1.7.3 era, so after all, I think 1) is the best for now. While I am not worried that much about bugfixes, going with 1) allows to shrink the installation footprint, because rubygem-racc can be installed only when really needed 2) we have experience with this approach. I'll go with this. Thx for feedback! Vít Regards, Mamoru -- ___ 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 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
Re: Conflicting racc
Mamoru TASAKA wrote on 2023/12/21 9:04: Vít Ondruch wrote on 2023/12/21 0:45: I have just hit this issue: ~~~ Error: Transaction test error: file /usr/lib64/gems/ruby/racc-1.7.3/racc/cparse.so from install of ruby-bundled-gems-3.3.0~20231219git8e6f63df47-184.fc40.x86_64 conflicts with file from package rubygem-racc-1.7.3-200.fc40.x86_64 file /usr/share/gems/specifications/racc-1.7.3.gemspec from install of ruby-bundled-gems-3.3.0~20231219git8e6f63df47-184.fc40.x86_64 conflicts with file from package rubygem-racc-1.7.3-200.fc40.x86_64 ~~~ The problem here is that racc is now bundled gem, where previously it was default gem, therefore there is now this conflict. How are we going to solve this? There are several options: 1) Make rubygem-racc subpackage of Ruby. We used to do this [1], but with default gem, the situation was different. 2) Install default gems / our system gems into dedicated directory, where they won't conflict. I was already proposing it elsewhere to explore the `gem install --vendor` or I have proposed upstream to have dedicated directories for default / bundled gems. Is it the right time to do this? 3) Drop the independent rubygem-racc Actually I am not sure how sever this situation is, because I have explicitly installed rubygem-racc prior the ruby-default-gems get chance to be installed. So maybe we still have some time to thing about it. Thoughts? Vít [1] https://src.fedoraproject.org/rpms/ruby/c/baf046a6a4d17fa309c9d20fa3db949f6c24aacf Because new version of racc (independent) gem may be released during ruby 3.3 stage (actually racc version 1.7.0 was released 2023/Jun) and when that happens, racc bundled in ruby 3.3 won't be updated, to make it possible to update rubygem-racc version, I don't think 3) is what we want (at least I don't want 3)) . I think 1) is the "simplest" way in that this is the least likely way where some misbehavior can happen. 2) can be the option, but I think we can defer to this for ruby 3.4. Or... 4) Make ruby-default-gems have "Obsoletes: rubygem-racc < 1.7.4" ? So this way, unless I am wrong: * when rubygem-racc-1.7.3-200.fc40 is firstly installed, rubygem-default-gems should Obsolete this independent rubygem-racc because of this. * when independent rubygem-racc version is updated, this Obsoletes no longer in effect, but as version differs between independent rubygem-racc and bundled one, so there should be no file conflict, perhaps? * Then when racc version in ruby-default-gems is updated, we can again have "Obsoletes: rubygem-racc < 1.7.5" in ruby-default-gems. At least, for current situation, 4) (i.e. use Obsoletes instead of dropping) should work. Anyway, thank you for pointing this out. After second thought, maybe some bugfix backport can happen even in rubygem-racc 1.7.3 era, so after all, I think 1) is the best for now. Regards, Mamoru -- ___ 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
Re: Conflicting racc
Vít Ondruch wrote on 2023/12/21 0:45: I have just hit this issue: ~~~ Error: Transaction test error: file /usr/lib64/gems/ruby/racc-1.7.3/racc/cparse.so from install of ruby-bundled-gems-3.3.0~20231219git8e6f63df47-184.fc40.x86_64 conflicts with file from package rubygem-racc-1.7.3-200.fc40.x86_64 file /usr/share/gems/specifications/racc-1.7.3.gemspec from install of ruby-bundled-gems-3.3.0~20231219git8e6f63df47-184.fc40.x86_64 conflicts with file from package rubygem-racc-1.7.3-200.fc40.x86_64 ~~~ The problem here is that racc is now bundled gem, where previously it was default gem, therefore there is now this conflict. How are we going to solve this? There are several options: 1) Make rubygem-racc subpackage of Ruby. We used to do this [1], but with default gem, the situation was different. 2) Install default gems / our system gems into dedicated directory, where they won't conflict. I was already proposing it elsewhere to explore the `gem install --vendor` or I have proposed upstream to have dedicated directories for default / bundled gems. Is it the right time to do this? 3) Drop the independent rubygem-racc Actually I am not sure how sever this situation is, because I have explicitly installed rubygem-racc prior the ruby-default-gems get chance to be installed. So maybe we still have some time to thing about it. Thoughts? Vít [1] https://src.fedoraproject.org/rpms/ruby/c/baf046a6a4d17fa309c9d20fa3db949f6c24aacf Because new version of racc (independent) gem may be released during ruby 3.3 stage (actually racc version 1.7.0 was released 2023/Jun) and when that happens, racc bundled in ruby 3.3 won't be updated, to make it possible to update rubygem-racc version, I don't think 3) is what we want (at least I don't want 3)) . I think 1) is the "simplest" way in that this is the least likely way where some misbehavior can happen. 2) can be the option, but I think we can defer to this for ruby 3.4. Or... 4) Make ruby-default-gems have "Obsoletes: rubygem-racc < 1.7.4" ? So this way, unless I am wrong: * when rubygem-racc-1.7.3-200.fc40 is firstly installed, rubygem-default-gems should Obsolete this independent rubygem-racc because of this. * when independent rubygem-racc version is updated, this Obsoletes no longer in effect, but as version differs between independent rubygem-racc and bundled one, so there should be no file conflict, perhaps? * Then when racc version in ruby-default-gems is updated, we can again have "Obsoletes: rubygem-racc < 1.7.5" in ruby-default-gems. At least, for current situation, 4) (i.e. use Obsoletes instead of dropping) should work. Anyway, thank you for pointing this out. Regards, Mamoru -- ___ 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
Conflicting racc
I have just hit this issue: ~~~ Error: Transaction test error: file /usr/lib64/gems/ruby/racc-1.7.3/racc/cparse.so from install of ruby-bundled-gems-3.3.0~20231219git8e6f63df47-184.fc40.x86_64 conflicts with file from package rubygem-racc-1.7.3-200.fc40.x86_64 file /usr/share/gems/specifications/racc-1.7.3.gemspec from install of ruby-bundled-gems-3.3.0~20231219git8e6f63df47-184.fc40.x86_64 conflicts with file from package rubygem-racc-1.7.3-200.fc40.x86_64 ~~~ The problem here is that racc is now bundled gem, where previously it was default gem, therefore there is now this conflict. How are we going to solve this? There are several options: 1) Make rubygem-racc subpackage of Ruby. We used to do this [1], but with default gem, the situation was different. 2) Install default gems / our system gems into dedicated directory, where they won't conflict. I was already proposing it elsewhere to explore the `gem install --vendor` or I have proposed upstream to have dedicated directories for default / bundled gems. Is it the right time to do this? 3) Drop the independent rubygem-racc Actually I am not sure how sever this situation is, because I have explicitly installed rubygem-racc prior the ruby-default-gems get chance to be installed. So maybe we still have some time to thing about it. Thoughts? Vít [1] https://src.fedoraproject.org/rpms/ruby/c/baf046a6a4d17fa309c9d20fa3db949f6c24aacf 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
