Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

We should also use rubygem(name) for the dependencies #284

Merged
merged 1 commit into from Nov 19, 2012

Conversation

@vStone
Copy link
Contributor

vStone commented Nov 5, 2012

We are currently having an issue with the dependencies.

RPM seems to add some magic

rubygem(fpm) = 0.4.20
rubygem-fpm = 1:0.4.20-1

Normally, I would expect the second provide string to be rubygem-fpm = 0.4.20-1 but it seems something changed. I have not tracked down what yet.

Anyhow, even besides that, this still is a good idea IMHO. We should depend on something we know our packages provide, not on rpm magic.

@vStone

This comment has been minimized.

Copy link
Contributor Author

vStone commented Nov 6, 2012

Looks like it is rpm (or rpmbuild or whatever is used) that adds the additional provides with the full packagename and prepended version (1:0.4.20).

@stahnma

This comment has been minimized.

Copy link

stahnma commented Nov 6, 2012

I'm not sure if this matters, but Perl is handled nearly identically in older EL type systems. You may want to make a case statement for that if people are packaging Perl via FPM as well.

@jordansissel

This comment has been minimized.

Copy link
Owner

jordansissel commented Nov 6, 2012

Curious - why does this matter?

If you build a gem from 'rails', you'll get rubygem-rails which provides rubygem(rails) and has dependencies like this:

Requires: rubygem-activesupport = 3.2.8

Now, if you build the 'activesupport' gem into an rpm with fpm, you'll get a gem that provides this as well, so your dependency heirarchy is maintained.

Is the desire here to follow redhat style? or is there a bug being fixed? I might be misreading, but I don't see an actual problem described that is fixed by the patch. Can you help me understand? :)

@jordansissel

This comment has been minimized.

Copy link
Owner

jordansissel commented Nov 6, 2012

I suppose my question is basically around what this solves. If you're using upstream rpms (say, from centos), they'll provide rubygem(foo), right? is the point to use fpm-built rpms that work with non-fpm-build rubygem rpms?

@vStone

This comment has been minimized.

Copy link
Contributor Author

vStone commented Nov 6, 2012

Since our last update, the packages have the following provide:

rpm -qp --provides rubygem-fpm-0.4.20-1.noarch.rpm 
rubygem(fpm) = 0.4.20
rubygem-fpm = 1:0.4.20-1

The 1:0.4.20-1 is really the blocker. It used to be:

rpm -qp --provides rubygem-fpm-0.4.10-1.noarch.rpm 
rubygem(fpm)  
rubygem-fpm = 0.4.10-1

I was unable to track the prefixing with 1: down to fpm so I imagine it must be something that rpmbuild adds.

In any case, to fix the requirements I though it was the easiest solution to use rubygem(fpm) as dependency style. It also seems more logic since most upstream packages indeed do also provide rubygem(name).

@jordansissel

This comment has been minimized.

Copy link
Owner

jordansissel commented Nov 6, 2012

Oh I see, the problem is that the rpm generated has a 'provides' that includes the epoch?

Why is that a problem? What problems does this cause?

@jordansissel

This comment has been minimized.

Copy link
Owner

jordansissel commented Nov 6, 2012

(the epoch being the '1' value in '1:0.4.10-1')

@vStone

This comment has been minimized.

Copy link
Contributor Author

vStone commented Nov 6, 2012

its a problem because the dependencies that fpm generates do not include it :)

@jordansissel

This comment has been minimized.

Copy link
Owner

jordansissel commented Nov 6, 2012

Ahha!

Ok so I think maybe the bug here is that epoch should default to nothing. RPMs are not required to have an epoch, iirc.

@vStone

This comment has been minimized.

Copy link
Contributor Author

vStone commented Nov 7, 2012

It's weird that this changes all of a sudden. I haven't been able to track down what changed between our previous builds besides the fpm upgrade to 0.4.20. But I couldn't even find anything related to the second added provide in fpm. The produced spec file (by fpm) doesn't contain that provide line at all.

@jordansissel

This comment has been minimized.

Copy link
Owner

jordansissel commented Nov 7, 2012

hmm, that's an interesting observation. Very strange

@vStone

This comment has been minimized.

Copy link
Contributor Author

vStone commented Nov 7, 2012

Hm, the change to the default 'provides' also seems to have a different side-effect:

Our packages with the same version are no longer updated, but installed along eachother:

up-puppet-tree-develop.noarch   1:1.0-252                                                                               
up-puppet-tree-develop.noarch   1:1.0-253                                                                             
up-puppet-tree-develop.noarch   1:1.0-254

IMHO, the default provides for these kind of packages should just be '1.0'

@vStone

This comment has been minimized.

Copy link
Contributor Author

vStone commented Nov 7, 2012

I've bisected the change to d8f2ac7

@RichardN

This comment has been minimized.

Copy link

RichardN commented Nov 19, 2012

Just wanted to +1 this problem. I use fpm to build rpm versions of the Opscode Chef gems and it is failing since installing 0.4.20.

rpm -i rubygem-chef-solr-10.16.2-1.noarch.rpm error: Failed dependencies:
rubygem-chef = 10.16.2 is needed by rubygem-chef-solr-10.16.2-1.noarch

jordansissel added a commit that referenced this pull request Nov 19, 2012
We should also use rubygem(name) for the dependencies
@jordansissel jordansissel merged commit 1252489 into jordansissel:master Nov 19, 2012
1 check passed
1 check passed
default The Travis build passed
Details
prof-milki pushed a commit to prof-milki/xpm that referenced this pull request Dec 18, 2014
We should also use rubygem(name) for the dependencies
prof-milki pushed a commit to prof-milki/xpm that referenced this pull request Dec 27, 2014
We should also use rubygem(name) for the dependencies
jordansissel added a commit that referenced this pull request Apr 24, 2015
We should also use rubygem(name) for the dependencies
jordansissel added a commit that referenced this pull request Jun 20, 2016
We should also use rubygem(name) for the dependencies
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.