Hi guys, I promise that this is my last mail today :)
Together with Vit, we have created a new Ruby packaging guidelines draft [1] and we would very much like you to go through it, so that we can discuss it here and change it for the best.
Regards, Bohuslav.
On 12/21/2011 06:36 AM, Bohuslav Kabrda wrote:
Hi guys, I promise that this is my last mail today :)
Together with Vit, we have created a new Ruby packaging guidelines draft [1] and we would very much like you to go through it, so that we can discuss it here and change it for the best.
Regards, Bohuslav.
[1] https://fedoraproject.org/wiki/PackagingDrafts/Ruby _______________________________________________ ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
Bohuslav, Vit, thank you both greatly for these updated guidelines (as well as anyone else I missed). Some comments.
- why is ruby-devel required as a BR for all non-gem packages, isn't this only needed for those packages containing native C code? An if this is legit, doesn't this obsolete the BR on ruby as that will be pulled in anyways?
- In the Rubygems section:
"For every dependency on a Gem named|gemdep|, the package must contain a|Requires| on|rubygem(%{gemdep})| with the same version constraints as the Gem"
Can this be a "should" or can we append a "where possible" onto the end of this. I've run into situations in the past where the constraints on the upstream gem are too restrictive, and infact the gem will work with a more lax gem set which we ship in Fedora
- "Since the Gem is installed using RPM, you*must* exclude the .gem file"
Can this be a "should" and/or something that is encouraged but not mandatory (perhaps recommend this be shipped as a supporting file, such as a %doc or a file in a debug package). Not a blocker for me, but would be nice to provide the original gem as part of the tarball for local reference
- In the "RubyGem with extension libraries written in C" section, I feel the guidelines could use some examples. I understand that these were copied in a large part from the existing guidelines, but things like "Then at|%build| stage the Ruby Gem*must* be installed under the directory created at|%prep| stage to get C libraries compiled under there." are somewhat confusing to me.
Perhaps a simple example of what this would look like in the actual specfile would go a long way to avoiding repetitive questions
- Do we still need the "Packaging for gem and non-gem use section", can't we get rid of that all together?
- Should the "Ruby Applications" section be located under "Rubygems". We can get rid of that and the bit about "these naming guidelines only apply to ruby packages whose ..." in the "Naming Guidelines" section by including the following in the initial "Ruby Packaging Guidelines" section at the very top:
These guidelines only apply to ruby packages whose main purpose is providing a Ruby library; packages that mainly provide user-level tools that happen to be written in Ruby do not need to follow these naming guidelines, and should follow the general Packaging Guidelines instead.
All in all, mostly small points. Thank you both again for taking the time to update these, they look really good.
-Mo
Dne 22.12.2011 14:17, Mo Morsi napsal(a):
On 12/21/2011 06:36 AM, Bohuslav Kabrda wrote:
Hi guys, I promise that this is my last mail today :)
Together with Vit, we have created a new Ruby packaging guidelines draft [1] and we would very much like you to go through it, so that we can discuss it here and change it for the best.
Regards, Bohuslav.
[1]https://fedoraproject.org/wiki/PackagingDrafts/Ruby _______________________________________________ ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
Bohuslav, Vit, thank you both greatly for these updated guidelines (as well as anyone else I missed). Some comments.
- why is ruby-devel required as a BR for all non-gem packages, isn't this only needed for those packages containing native C code? An if this is legit, doesn't this obsolete the BR on ruby as that will be pulled in anyways?
We have introduce '/etc/rpm/macros.ruby' file, which provides all macros used for ruby packaging. As this is clearly no run-time dependency, we decided to place it into -devel package, therefore the ruby-devel package is always needed.
So you are right, we should remove the BR: ruby. Good point.
- In the Rubygems section:
"For every dependency on a Gem named|gemdep|, the package must contain a|Requires| on|rubygem(%{gemdep})| with the same version constraints as the Gem"
Can this be a "should" or can we append a "where possible" onto the end of this. I've run into situations in the past where the constraints on the upstream gem are too restrictive, and infact the gem will work with a more lax gem set which we ship in Fedora
You are right. We should not be as strict. Actually, I believe that we should not use version unless necessary. We will try to polish this formulation according to your suggestion.
- "Since the Gem is installed using RPM, you*must* exclude the .gem file"
Can this be a "should" and/or something that is encouraged but not mandatory (perhaps recommend this be shipped as a supporting file, such as a %doc or a file in a debug package). Not a blocker for me, but would be nice to provide the original gem as part of the tarball for local reference
Well, I believe that "should" does not solve anything, because whenever you'll like to use the gem, you realize, that you are out of luck, because you are using gem without the cached package by coincidence.
Could you elaborate what is your usecase? I use the local gem only by calling "gem pristine" and this call should be replaced by RPM equivalent. So I see no reason to keep the gem. It is just unnecessary payload.
- In the "RubyGem with extension libraries written in C" section, I feel the guidelines could use some examples. I understand that these were copied in a large part from the existing guidelines, but things like "Then at|%build| stage the Ruby Gem*must* be installed under the directory created at|%prep| stage to get C libraries compiled under there." are somewhat confusing to me.
Perhaps a simple example of what this would look like in the actual specfile would go a long way to avoiding repetitive questions
Great idea! I always like to copy/paste examples :)
- Do we still need the "Packaging for gem and non-gem use section", can't we get rid of that all together?
Well, there is the legacy note which should warn the packagers. Actually I agree with you that we should get rid of it. However, there are gems which still have the ruby- subpackage and they would be outlawed by this change immediately.
What are opinions/suggestions? May be we could setup some deadline, when we should get rid of them ...
- Should the "Ruby Applications" section be located under "Rubygems".
They should be h2, i.e. on the same structure level as Rubygems.
We can get rid of that and the bit about "these naming guidelines only apply to ruby packages whose ..." in the "Naming Guidelines" section by including the following in the initial "Ruby Packaging Guidelines" section at the very top:
These guidelines only apply to ruby packages whose main purpose is providing a Ruby library; packages that mainly provide user-level tools that happen to be written in Ruby do not need to follow these naming guidelines, and should follow the general Packaging Guidelines instead.
Actually, I like to have separate section, because there is a lot of confusion what is application and what is not, if something which is coming packaged as a gem could be application or has to be packaged as gem. For example, I remember review of "deltacloud-core", which is available as a gem, however, we extracted the gem out of original location, enriched it by init scripts etc. So at the end, from the resulting package, it is not obvious that the upstream is available as a gem.
So although the section is not exhaustive, I would like to provide better guidance to somebody, who likes to package something similar.
All in all, mostly small points. Thank you both again for taking the time to update these, they look really good.
Thank you for your great feedback!
-Mo
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
On 12/22/2011 09:09 AM, Vít Ondruch wrote:
- "Since the Gem is installed using RPM, you*must* exclude the .gem file"
Can this be a "should" and/or something that is encouraged but not mandatory (perhaps recommend this be shipped as a supporting file, such as a %doc or a file in a debug package). Not a blocker for me, but would be nice to provide the original gem as part of the tarball for local reference
Well, I believe that "should" does not solve anything, because whenever you'll like to use the gem, you realize, that you are out of luck, because you are using gem without the cached package by coincidence.
Could you elaborate what is your usecase? I use the local gem only by calling "gem pristine" and this call should be replaced by RPM equivalent. So I see no reason to keep the gem. It is just unnecessary payload.
Aight fair enough. Not a biggie for me as the package can be easily d/l from rubygems.
- Do we still need the "Packaging for gem and non-gem use section", can't we get rid of that all together?
Well, there is the legacy note which should warn the packagers. Actually I agree with you that we should get rid of it. However, there are gems which still have the ruby- subpackage and they would be outlawed by this change immediately.
What are opinions/suggestions? May be we could setup some deadline, when we should get rid of them ...
That's a good idea. Any idea on how many gems still ship a non-gem subpackage?
- Should the "Ruby Applications" section be located under "Rubygems".
They should be h2, i.e. on the same structure level as Rubygems.
We can get rid of that and the bit about "these naming guidelines only apply to ruby packages whose ..." in the "Naming Guidelines" section by including the following in the initial "Ruby Packaging Guidelines" section at the very top:
These guidelines only apply to ruby packages whose main purpose is providing a Ruby library; packages that mainly provide user-level tools that happen to be written in Ruby do not need to follow these naming guidelines, and should follow the general Packaging Guidelines instead.
Actually, I like to have separate section, because there is a lot of confusion what is application and what is not, if something which is coming packaged as a gem could be application or has to be packaged as gem. For example, I remember review of "deltacloud-core", which is available as a gem, however, we extracted the gem out of original location, enriched it by init scripts etc. So at the end, from the resulting package, it is not obvious that the upstream is available as a gem.
So although the section is not exhaustive, I would like to provide better guidance to somebody, who likes to package something similar.
Sounds good to me.
-Mo
On 12/22/2011 09:09 AM, Vít Ondruch wrote:
- In the Rubygems section:
"For every dependency on a Gem named|gemdep|, the package must contain a|Requires| on|rubygem(%{gemdep})| with the same version constraints as the Gem"
Can this be a "should" or can we append a "where possible" onto the end of this. I've run into situations in the past where the constraints on the upstream gem are too restrictive, and infact the gem will work with a more lax gem set which we ship in Fedora
You are right. We should not be as strict. Actually, I believe that we should not use version unless necessary. We will try to polish this formulation according to your suggestion.
Actually, we need to be very careful here. We've been bitten in the past by creating RPMs with deps that don't strictly follow the gem deps, since you then have a gem installed that, strictly speaking, doesn't meet its gem dep requirements. If you end up using bundler for something, it's going to complain. We had a big problem with this when we had an RPM for which the underlying gem required rspec (2.0+), but we required the rspec sub-packages instead.
Scott
On 12/22/2011 11:19 AM, Scott Seago wrote:
On 12/22/2011 09:09 AM, Vít Ondruch wrote:
- In the Rubygems section:
"For every dependency on a Gem named|gemdep|, the package must contain a|Requires| on|rubygem(%{gemdep})| with the same version constraints as the Gem"
Can this be a "should" or can we append a "where possible" onto the end of this. I've run into situations in the past where the constraints on the upstream gem are too restrictive, and infact the gem will work with a more lax gem set which we ship in Fedora
You are right. We should not be as strict. Actually, I believe that we should not use version unless necessary. We will try to polish this formulation according to your suggestion.
Actually, we need to be very careful here. We've been bitten in the past by creating RPMs with deps that don't strictly follow the gem deps, since you then have a gem installed that, strictly speaking, doesn't meet its gem dep requirements. If you end up using bundler for something, it's going to complain. We had a big problem with this when we had an RPM for which the underlying gem required rspec (2.0+), but we required the rspec sub-packages instead.
Scott
Ah good point. Actually now that I think about it the guidelines could use something to the effect of how to integrate bundler and other alternative gem-dependency management into all of this (its been a royal pain up to this point).
If nothing else, perhaps a guideline stating that if you modify the gem dependency list in the rpm spec, you must ensure that it is modified in bundler's Gemfile as well.
Actually expanding upon this, I'd love to see the work that Jay did with making bundler usage toggleable in conductor, a more generic plugin, able to be pulled into any project. Jay any thoughts on the feasibility of this?
-Mo
On 12/22/2011 11:45 AM, Mo Morsi wrote:
On 12/22/2011 11:19 AM, Scott Seago wrote:
On 12/22/2011 09:09 AM, Vít Ondruch wrote:
- In the Rubygems section:
"For every dependency on a Gem named|gemdep|, the package must contain a|Requires| on|rubygem(%{gemdep})| with the same version constraints as the Gem"
Can this be a "should" or can we append a "where possible" onto the end of this. I've run into situations in the past where the constraints on the upstream gem are too restrictive, and infact the gem will work with a more lax gem set which we ship in Fedora
You are right. We should not be as strict. Actually, I believe that we should not use version unless necessary. We will try to polish this formulation according to your suggestion.
Actually, we need to be very careful here. We've been bitten in the past by creating RPMs with deps that don't strictly follow the gem deps, since you then have a gem installed that, strictly speaking, doesn't meet its gem dep requirements. If you end up using bundler for something, it's going to complain. We had a big problem with this when we had an RPM for which the underlying gem required rspec (2.0+), but we required the rspec sub-packages instead.
Scott
Ah good point. Actually now that I think about it the guidelines could use something to the effect of how to integrate bundler and other alternative gem-dependency management into all of this (its been a royal pain up to this point).
If nothing else, perhaps a guideline stating that if you modify the gem dependency list in the rpm spec, you must ensure that it is modified in bundler's Gemfile as well.
Actually expanding upon this, I'd love to see the work that Jay did with making bundler usage toggleable in conductor, a more generic plugin, able to be pulled into any project. Jay any thoughts on the feasibility of this?
-Mo
Well the particular problem wasn't because bundler deps were mismatched. We were hitting problems because we didn't have all gems required in the gemspec weren't installed. Basically, if source isn't commented out in Gemfile, if we have a gem installed without its deps, bundler will install it (resulting in a gem _not_ from the fedora repos as a gem RPM in your dep chain. If source _is_ commented out (which is how we handle bundler for conductor on fedora -- to keep random different versions of Gems from being installed) we get errors about required gems not being available.
So, this brings us back to if the gemspec requires $foo, then our RPM had better require rubygem($foo) or we're asking for trouble down the line.
Scott
Dne 22.12.2011 18:24, Scott Seago napsal(a):
On 12/22/2011 11:45 AM, Mo Morsi wrote:
On 12/22/2011 11:19 AM, Scott Seago wrote:
On 12/22/2011 09:09 AM, Vít Ondruch wrote:
- In the Rubygems section:
"For every dependency on a Gem named|gemdep|, the package must contain a|Requires| on|rubygem(%{gemdep})| with the same version constraints as the Gem"
Can this be a "should" or can we append a "where possible" onto the end of this. I've run into situations in the past where the constraints on the upstream gem are too restrictive, and infact the gem will work with a more lax gem set which we ship in Fedora
You are right. We should not be as strict. Actually, I believe that we should not use version unless necessary. We will try to polish this formulation according to your suggestion.
Actually, we need to be very careful here. We've been bitten in the past by creating RPMs with deps that don't strictly follow the gem deps, since you then have a gem installed that, strictly speaking, doesn't meet its gem dep requirements. If you end up using bundler for something, it's going to complain. We had a big problem with this when we had an RPM for which the underlying gem required rspec (2.0+), but we required the rspec sub-packages instead.
Scott
Ah good point. Actually now that I think about it the guidelines could use something to the effect of how to integrate bundler and other alternative gem-dependency management into all of this (its been a royal pain up to this point).
If nothing else, perhaps a guideline stating that if you modify the gem dependency list in the rpm spec, you must ensure that it is modified in bundler's Gemfile as well.
Actually expanding upon this, I'd love to see the work that Jay did with making bundler usage toggleable in conductor, a more generic plugin, able to be pulled into any project. Jay any thoughts on the feasibility of this?
-Mo
Well the particular problem wasn't because bundler deps were mismatched. We were hitting problems because we didn't have all gems required in the gemspec weren't installed. Basically, if source isn't commented out in Gemfile, if we have a gem installed without its deps, bundler will install it (resulting in a gem _not_ from the fedora repos as a gem RPM in your dep chain. If source _is_ commented out (which is how we handle bundler for conductor on fedora -- to keep random different versions of Gems from being installed) we get errors about required gems not being available.
So, this brings us back to if the gemspec requires $foo, then our RPM had better require rubygem($foo) or we're asking for trouble down the line.
Actually the original discussion was about *versioned* dependencies.
However, it is packager's responsibility to provide correct RPM dependencies. There is a lot of cases when to not follow the default dependencies for several reasons. You can take Rails as an example again. We are not closely following the gem dependencies, because the gem dependencies does not reflect reality. However, it is good for us to not follow them, because it might simplify our build process. If that causes troubles, well be it, it's a bug which needs to be solved. But I take the original gem dependencies just as a guideline and nothing more.
One more thing. We have Rawhide where the development should happen. Rawhide have freeze period when you should polish your packages etc. Once the Rawhide turns into stable Fedora version, there should not land any new Feature without good reason. If you want do it, you are asking yourself more troubles. This approach allows you to focus just to one version of Fedora, i.e. Rawhide and once it is released, you don't have any troubles, because you had plenty of time to polish issues such as wrong dependency.
Vit
Scott
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
Dne 22.12.2011 17:45, Mo Morsi napsal(a):
On 12/22/2011 11:19 AM, Scott Seago wrote:
On 12/22/2011 09:09 AM, Vít Ondruch wrote:
- In the Rubygems section:
"For every dependency on a Gem named|gemdep|, the package must contain a|Requires| on|rubygem(%{gemdep})| with the same version constraints as the Gem"
Can this be a "should" or can we append a "where possible" onto the end of this. I've run into situations in the past where the constraints on the upstream gem are too restrictive, and infact the gem will work with a more lax gem set which we ship in Fedora
You are right. We should not be as strict. Actually, I believe that we should not use version unless necessary. We will try to polish this formulation according to your suggestion.
Actually, we need to be very careful here. We've been bitten in the past by creating RPMs with deps that don't strictly follow the gem deps, since you then have a gem installed that, strictly speaking, doesn't meet its gem dep requirements. If you end up using bundler for something, it's going to complain. We had a big problem with this when we had an RPM for which the underlying gem required rspec (2.0+), but we required the rspec sub-packages instead.
Scott
Ah good point. Actually now that I think about it the guidelines could use something to the effect of how to integrate bundler and other alternative gem-dependency management into all of this (its been a royal pain up to this point).
If nothing else, perhaps a guideline stating that if you modify the gem dependency list in the rpm spec, you must ensure that it is modified in bundler's Gemfile as well.
Something more important should be there. If RPM modifies some gems dependencies, then the .gemspec should be updated accordingly. I know that I forget to do it several times and there were probably also others.
Gemfile is next level and I still find use of Bundler dangerous and useless for two reasons:
1) It installs non RPM dependencies, where the dependencies should be solved always by packager 2) Bundler should solve the version conflicts in case you have more versions of gem on your system, but in Fedora, you doesn't have.
However, I might be oversimplifying the situation, because users may install their own gem with different versions :/
Actually expanding upon this, I'd love to see the work that Jay did with making bundler usage toggleable in conductor, a more generic plugin, able to be pulled into any project. Jay any thoughts on the feasibility of this?
-Mo
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
On 12/23/2011 04:39 AM, Vít Ondruch wrote:
Dne 22.12.2011 17:45, Mo Morsi napsal(a):
On 12/22/2011 11:19 AM, Scott Seago wrote:
On 12/22/2011 09:09 AM, Vít Ondruch wrote:
- In the Rubygems section:
"For every dependency on a Gem named|gemdep|, the package must contain a|Requires| on|rubygem(%{gemdep})| with the same version constraints as the Gem"
Can this be a "should" or can we append a "where possible" onto the end of this. I've run into situations in the past where the constraints on the upstream gem are too restrictive, and infact the gem will work with a more lax gem set which we ship in Fedora
You are right. We should not be as strict. Actually, I believe that we should not use version unless necessary. We will try to polish this formulation according to your suggestion.
Actually, we need to be very careful here. We've been bitten in the past by creating RPMs with deps that don't strictly follow the gem deps, since you then have a gem installed that, strictly speaking, doesn't meet its gem dep requirements. If you end up using bundler for something, it's going to complain. We had a big problem with this when we had an RPM for which the underlying gem required rspec (2.0+), but we required the rspec sub-packages instead.
Scott
Ah good point. Actually now that I think about it the guidelines could use something to the effect of how to integrate bundler and other alternative gem-dependency management into all of this (its been a royal pain up to this point).
If nothing else, perhaps a guideline stating that if you modify the gem dependency list in the rpm spec, you must ensure that it is modified in bundler's Gemfile as well.
Something more important should be there. If RPM modifies some gems dependencies, then the .gemspec should be updated accordingly. I know that I forget to do it several times and there were probably also others.
Yes, this is exactly my point -- the problem I ran into was when we modified the RPM deps in a way that contradicted the gemspec, but the gemspec wasn't modified accordingly. If RPM deps are modified and the gemspec is modified accordingly, the conflict goes away. The main point is that if the installed gem has missing deps, we have a problem. If we modified the gemspec to reflect the RPM deps, then any ruby code that cares about gem dependencies (such as bundler) will continue to work fine.
Gemfile is next level and I still find use of Bundler dangerous and useless for two reasons:
- It installs non RPM dependencies, where the dependencies should be
solved always by packager 2) Bundler should solve the version conflicts in case you have more versions of gem on your system, but in Fedora, you doesn't have.
However, I might be oversimplifying the situation, because users may install their own gem with different versions :/
Actually expanding upon this, I'd love to see the work that Jay did with making bundler usage toggleable in conductor, a more generic plugin, able to be pulled into any project. Jay any thoughts on the feasibility of this?
-Mo
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
Dne 3.1.2012 16:07, Scott Seago napsal(a):
On 12/23/2011 04:39 AM, Vít Ondruch wrote:
Dne 22.12.2011 17:45, Mo Morsi napsal(a):
On 12/22/2011 11:19 AM, Scott Seago wrote:
On 12/22/2011 09:09 AM, Vít Ondruch wrote:
- In the Rubygems section:
"For every dependency on a Gem named|gemdep|, the package must contain a|Requires| on|rubygem(%{gemdep})| with the same version constraints as the Gem"
Can this be a "should" or can we append a "where possible" onto the end of this. I've run into situations in the past where the constraints on the upstream gem are too restrictive, and infact the gem will work with a more lax gem set which we ship in Fedora
You are right. We should not be as strict. Actually, I believe that we should not use version unless necessary. We will try to polish this formulation according to your suggestion.
Actually, we need to be very careful here. We've been bitten in the past by creating RPMs with deps that don't strictly follow the gem deps, since you then have a gem installed that, strictly speaking, doesn't meet its gem dep requirements. If you end up using bundler for something, it's going to complain. We had a big problem with this when we had an RPM for which the underlying gem required rspec (2.0+), but we required the rspec sub-packages instead.
Scott
Ah good point. Actually now that I think about it the guidelines could use something to the effect of how to integrate bundler and other alternative gem-dependency management into all of this (its been a royal pain up to this point).
If nothing else, perhaps a guideline stating that if you modify the gem dependency list in the rpm spec, you must ensure that it is modified in bundler's Gemfile as well.
Something more important should be there. If RPM modifies some gems dependencies, then the .gemspec should be updated accordingly. I know that I forget to do it several times and there were probably also others.
Yes, this is exactly my point -- the problem I ran into was when we modified the RPM deps in a way that contradicted the gemspec, but the gemspec wasn't modified accordingly. If RPM deps are modified and the gemspec is modified accordingly, the conflict goes away. The main point is that if the installed gem has missing deps, we have a problem. If we modified the gemspec to reflect the RPM deps, then any ruby code that cares about gem dependencies (such as bundler) will continue to work fine.
We tried to work on the draft a bit. This is formulation we came up with:
The package must provide rubygem(%{gem_name}) where gem_name is the name from the Gem's specification. For every dependency on a Gem named gemdep, the package must contain a Requires on rubygem(%{gemdep}). Packager must ensure that the package works properly with its specified dependencies. Please note, that Fedora may carry different versions of Gems than those specified in Gem's .gemspec, therefore the versions required in specfile may not match the dependencies in .gemspec exactly. In that case, the .gemspec file must be adjusted accordingly.
Vit
Dne 22.12.2011 17:19, Scott Seago napsal(a):
On 12/22/2011 09:09 AM, Vít Ondruch wrote:
- In the Rubygems section:
"For every dependency on a Gem named|gemdep|, the package must contain a|Requires| on|rubygem(%{gemdep})| with the same version constraints as the Gem"
Can this be a "should" or can we append a "where possible" onto the end of this. I've run into situations in the past where the constraints on the upstream gem are too restrictive, and infact the gem will work with a more lax gem set which we ship in Fedora
You are right. We should not be as strict. Actually, I believe that we should not use version unless necessary. We will try to polish this formulation according to your suggestion.
Actually, we need to be very careful here. We've been bitten in the past by creating RPMs with deps that don't strictly follow the gem deps, since you then have a gem installed that, strictly speaking, doesn't meet its gem dep requirements. If you end up using bundler for something, it's going to complain. We had a big problem with this when we had an RPM for which the underlying gem required rspec (2.0+), but we required the rspec sub-packages instead.
Scott
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
Scott,
I understand your point, unfortunately there is not good solution. In Fedora, if you are *not* developer, then you have always one set of packages which should work together and this should be ensured by its packagers, i.e. the packagers in Fedora should replace the Bundler in Ruby world. I know, its probably to much should but that is how it works. Let me give you one example I remember:
If you are using Rails 3, their dependency says that they needs Rack ~> 1.3. However, we had in Fedora just Rack 1.1 and unresponsive maintainer. So how would you solve it? We chosen to relax the Rails dependency to ~> Rack 1.1 and everything worked just fine. However, if you used your Gemfile.lock, it obviously either did not work on other platforms or did not worked for Fedora. So in this case you can either:
1) Do not use Bundler. 2) Provide more Gemfile.lock, for each Fedora version etc.
Generally I am fan of 1) and I would say we are using it quite often already. There is plenty of gems which are trying to use Bundler to execute their test suite and the best solution IMO is just to remove "require 'bundler/setup'" and you don't rely on the Bundler anymore.
Btw the problem with RSpec might be of two natures. Either you tried to use Gemfile.lock which was not specific for the Fedora you used or it was bug in packaging, i.e. the packager specified some RPM requirements, but forgot to update the .gemspec to proper versions. Speaking about that, we should note how to do that.
Vit
On 12/23/2011 04:31 AM, Vít Ondruch wrote:
Dne 22.12.2011 17:19, Scott Seago napsal(a):
On 12/22/2011 09:09 AM, Vít Ondruch wrote:
- In the Rubygems section:
"For every dependency on a Gem named|gemdep|, the package must contain a|Requires| on|rubygem(%{gemdep})| with the same version constraints as the Gem"
Can this be a "should" or can we append a "where possible" onto the end of this. I've run into situations in the past where the constraints on the upstream gem are too restrictive, and infact the gem will work with a more lax gem set which we ship in Fedora
You are right. We should not be as strict. Actually, I believe that we should not use version unless necessary. We will try to polish this formulation according to your suggestion.
Actually, we need to be very careful here. We've been bitten in the past by creating RPMs with deps that don't strictly follow the gem deps, since you then have a gem installed that, strictly speaking, doesn't meet its gem dep requirements. If you end up using bundler for something, it's going to complain. We had a big problem with this when we had an RPM for which the underlying gem required rspec (2.0+), but we required the rspec sub-packages instead.
Scott
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
Scott,
I understand your point, unfortunately there is not good solution. In Fedora, if you are *not* developer, then you have always one set of packages which should work together and this should be ensured by its packagers, i.e. the packagers in Fedora should replace the Bundler in Ruby world. I know, its probably to much should but that is how it works. Let me give you one example I remember:
If you are using Rails 3, their dependency says that they needs Rack ~> 1.3. However, we had in Fedora just Rack 1.1 and unresponsive maintainer. So how would you solve it? We chosen to relax the Rails dependency to ~> Rack 1.1 and everything worked just fine. However, if you used your Gemfile.lock, it obviously either did not work on other platforms or did not worked for Fedora. So in this case you can either:
- Do not use Bundler.
- Provide more Gemfile.lock, for each Fedora version etc.
Generally I am fan of 1) and I would say we are using it quite often already. There is plenty of gems which are trying to use Bundler to execute their test suite and the best solution IMO is just to remove "require 'bundler/setup'" and you don't rely on the Bundler anymore.
Btw the problem with RSpec might be of two natures. Either you tried to use Gemfile.lock which was not specific for the Fedora you used or it was bug in packaging, i.e. the packager specified some RPM requirements, but forgot to update the .gemspec to proper versions. Speaking about that, we should note how to do that.
Yes, the issue with rspec was the second one. The RPM deps were modified from the gemspec, but the gem itself was left untouched.
Scott
ruby-sig@lists.fedoraproject.org
-
Bohuslav Kabrda -
Mo Morsi -
Scott Seago -
Vít Ondruch