Bug 1838056

Summary: Review Request: rubygem-ipaddr - A class to manipulate an IP address in ruby
Product: [Fedora] Fedora Reporter: Pavel Valena <pvalena>
Component: Package ReviewAssignee: Nobody's working on this, feel free to take it <nobody>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: eclipseo, package-review, vondruch
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-06-30 07:22:43 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Comment 1 Vít Ondruch 2020-06-10 11:58:12 UTC
Could you please elaborate about the use case? Is it really necessary? What package depends on it?

Comment 2 Pavel Valena 2020-06-10 19:59:33 UTC
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).

Comment 3 Vít Ondruch 2020-06-11 08:11:57 UTC
(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

Comment 4 Pavel Valena 2020-06-11 10:03:01 UTC
(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.

Comment 5 Vít Ondruch 2020-06-11 10:44:36 UTC
(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.

Comment 6 Vít Ondruch 2020-06-11 10:46:29 UTC
(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?

Comment 7 Vít Ondruch 2020-06-11 10:49:16 UTC
(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.

Comment 8 Robert-André Mauchin 🐧 2020-06-26 20:42:27 UTC
Is this ready for review or do you wish to drop it?

Comment 9 Pavel Valena 2020-06-30 07:22:43 UTC
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/