Fedora Account System
Red Hat Associate
Red Hat Customer
Spec URL: https://download.copr.fedorainfracloud.org/results/pvalena/rubygems/fedora-rawhide-x86_64/01392920-rubygem-ipaddr/rubygem-ipaddr.spec SRPM URL: https://download.copr.fedorainfracloud.org/results/pvalena/rubygems/fedora-rawhide-x86_64/01392920-rubygem-ipaddr/rubygem-ipaddr-1.2.2-1.fc33.src.rpm Description: IPAddr provides a set of methods to manipulate an IP address. Both IPv4 and IPv6 are supported. Fedora Account System Username: pvalena Copr build: https://copr.fedorainfracloud.org/coprs/pvalena/rubygems/build/1392920/ Koji scratch-build: https://koji.fedoraproject.org/koji/taskinfo?taskID=44643341
Could you please elaborate about the use case? Is it really necessary? What package depends on it?
It is a `default` gem, but AFAIK there's no `Provides: rubygem(ipaddr)` in ruby-default-gems, right? It would be handy as an alternative, while because ruby-default-gems can may not be present on the installed system while Vagrant is. AFAIR I've run into some issues while debugging, and I've thought having `ipaddr` (and others like `reline`) default gems as a standalone packages might be benefitial (f.e. `reline` is needed for `irb` to run; so while I have irb installed I cannot run it, because I don't have ruby-default-gems).
(In reply to Pavel Valena from comment #2) > It is a `default` gem, but AFAIK there's no `Provides: rubygem(ipaddr)` in > ruby-default-gems, right? There is not such provide, because it is default gem, right? There seems to be 6 gems in total, which depends on IPAddr explicitly: https://rubygems.org/gems/ipaddr/reverse_dependencies > It would be handy as an alternative, while because ruby-default-gems can may > not be present on the installed system while Vagrant is. ruby-default-gems ships just .gemspec files, not the libraries. The code is on the system. There would need to be either some dependency in the .gemspec, which is probably not given the above, or there have to be some `gem "ipaddr"` call somewhere. Otherwise everything have to work even without ruby-default-gems. > AFAIR I've run into some issues while debugging, and I've thought having > `ipaddr` (and others like `reline`) default gems as a standalone packages > might be benefitial (f.e. `reline` is needed for `irb` to run; so while I > have irb installed I cannot run it, because I don't have ruby-default-gems). I don't want to see us duplicating the StdLib content. It never did anything good. It duplicates content, making us fixing the issues twice and we typically do bad job maintaining these libraries. So what is th real problem you are trying to solve? I would like to see backtrace or what not. BTW we already had issue which is related to this: https://bugzilla.redhat.com/show_bug.cgi?id=1838185
(In reply to Vít Ondruch from comment #3) > (In reply to Pavel Valena from comment #2) > > It is a `default` gem, but AFAIK there's no `Provides: rubygem(ipaddr)` in > > ruby-default-gems, right? > > There is not such provide, because it is default gem, right? There seems to > be 6 gems in total, which depends on IPAddr explicitly: Right, there was no gemspec dependency I, but it may have been Vagrant doing the 'version fixing' it does when it starts. Anyway, the issue went away (not sure where I've seen it exactly, so no reproducer, sorry). > > https://rubygems.org/gems/ipaddr/reverse_dependencies > > > It would be handy as an alternative, while because ruby-default-gems can may > > not be present on the installed system while Vagrant is. > > ruby-default-gems ships just .gemspec files, not the libraries. The code is > on the system. There would need to be either some dependency in the > .gemspec, which is probably not given the above, or there have to be some > `gem "ipaddr"` call somewhere. Otherwise everything have to work even > without ruby-default-gems. Ok, right, my mistake. Thanks for clearing this up. So maybe it was some `gem "ipaddr"` call, but I was not able to find the reference to that. > > > AFAIR I've run into some issues while debugging, and I've thought having > > `ipaddr` (and others like `reline`) default gems as a standalone packages > > might be benefitial (f.e. `reline` is needed for `irb` to run; so while I > > have irb installed I cannot run it, because I don't have ruby-default-gems). > > I don't want to see us duplicating the StdLib content. It never did anything > good. It duplicates content, making us fixing the issues twice and we > typically do bad job maintaining these libraries. Ok, point taken. There's no point in pushing this currently. > > So what is th real problem you are trying to solve? I would like to see > backtrace or what not. > > BTW we already had issue which is related to this: > https://bugzilla.redhat.com/show_bug.cgi?id=1838185 Yes, I see. But solution for that was to defer the `gem ...` call until it gets removed from stdlib. The only issue I can currently point to is the one with `reline`: https://gist.github.com/pvalena/760828f769f96752538554b27a63e88a IOW `irb` is unusable when ruby-default-gems is not installed.
(In reply to Pavel Valena from comment #4) > The only issue I can currently point to is the one with `reline`: > > https://gist.github.com/pvalena/760828f769f96752538554b27a63e88a > > IOW `irb` is unusable when ruby-default-gems is not installed. Yes, I have noticed and you are right. However, there are two issues: 1) This is issue mostly for mock, because mock does not install soft dependencies. 2) This is upstream issue, because there is no upstream guidance what is the right approach. IOW upstream is inconsistent. All parts of StdLib should either specify all their dependencies in spec file or they should not specify them at all. I think the first variant is correct and then we would be in better position to evaluate what is the right fix. However historically, the later approach was applied with various degree of success and without understanding what impact this is going to have. Anyway, this is discussion for different ticket, ideally upstream asking to properly reference all the dependencies or drop them.
(In reply to Vít Ondruch from comment #5) > 1) This is issue mostly for mock, because mock does not install soft dependencies. Actually, taking second look, it is not reproducer from mock and the soft dependencies are installed. So maybe we should really add some ruby-default-gems dependency somewhere. Could you please report this separately?
(In reply to Vít Ondruch from comment #6) > (In reply to Vít Ondruch from comment #5) > > 1) This is issue mostly for mock, because mock does not install soft dependencies. > > Actually, taking second look, it is not reproducer from mock and the soft > dependencies are installed. So maybe we should really add some > ruby-default-gems dependency somewhere. Could you please report this > separately? Ah, you exclude the package explicitly. It should be installed by default as a reverse soft dependency of rubygems package.
Is this ready for review or do you wish to drop it?
Let's drop this, following the discussion, to avoid duplicating stdlib. In need, the package is in my COPR: https://copr.fedorainfracloud.org/coprs/pvalena/rubygems/package/rubygem-ipaddr/