Replying to list to get wider discussion.
Posted by Bohuslav "Slavek" Kabrda on 2012-07-13 04:21:44 EDT to https://bugzilla.redhat.com/show_bug.cgi?id=825495 [Review Request: redmine]
Emanuel, I'm not sure we want redmine in Fedora. It would make us always have its specified version of rails. I don't think we want to have our hands tied with that. What if we want to get rails 4 (when they get released) into Fedora and redmine still relies on 3.2.3? This would limit us greatly, I have to say I am against that.
A solution to your problem might be creating a software collection [1], [2], which would be independent on system Gems versions. Unfortunately, software collections are not allowed into Fedora [3] - but I believe that if enough users would want to use them for projects like this, FPC would allow them. Redmine is a great candidate for a software collection, I think
[1]
http://docs.fedoraproject.org/en-US/Fedora_Contributor_Documentation/1/html/...
https://fedoraproject.org/wiki/Packaging:Guidelines#Software_Collection_Macr...
What I want to achieve with this redmine package is:
- a high quality package by getting feedback from the community - an easy installation with sane defaults for redmine users
A software collection goes part of the way there, but has some disadvantages by not being a first class citizen of Fedora.
When the rails community drops support for rails version 3, it should not be wise to still run Redmine installations for rails 3. At that time, we should work with upstream to make redmine work on rails 4.
When rails 4 is released but rails 3 is still supported, I see no reason why we could not have rails 3 and rails 4 side by side in Fedora. We do it for packages like python too.
Do you think having redmine in Fedora would limit your freedom to move the Fedora versions at the same speed that the upstream community is moving? Why? Should this problem be solved in Fedora or in the application (redmine upstream)? How can a package maintainer help?
Thank you for your comment,
Emanuel
On Wednesday, July 18, 2012 10:36:11 AM Emanuel Rietveld wrote:
Replying to list to get wider discussion.
Posted by Bohuslav "Slavek" Kabrda on 2012-07-13 04:21:44 EDT to https://bugzilla.redhat.com/show_bug.cgi?id=825495 [Review Request: redmine]
Emanuel, I'm not sure we want redmine in Fedora. It would make us always have its specified version of rails. I don't think we want to have our hands tied with that. What if we want to get rails 4 (when they get released) into Fedora and redmine still relies on 3.2.3? This would limit us greatly, I have to say I am against that.
A solution to your problem might be creating a software collection [1], [2], which would be independent on system Gems versions. Unfortunately, software collections are not allowed into Fedora [3] - but I believe that if enough users would want to use them for projects like this, FPC would allow them. Redmine is a great candidate for a software collection, I think
[1]
http://docs.fedoraproject.org/en-US/Fedora_Contributor_Documentation/1/html/ Software_Collections_Guide/index.html
https://fedoraproject.org/wiki/Packaging:Guidelines#Software_Collection_Macr os
What I want to achieve with this redmine package is:
- a high quality package by getting feedback from the community
- an easy installation with sane defaults for redmine users
A software collection goes part of the way there, but has some disadvantages by not being a first class citizen of Fedora.
When the rails community drops support for rails version 3, it should not be wise to still run Redmine installations for rails 3. At that time, we should work with upstream to make redmine work on rails 4.
When rails 4 is released but rails 3 is still supported, I see no reason why we could not have rails 3 and rails 4 side by side in Fedora. We do it for packages like python too.
Do you think having redmine in Fedora would limit your freedom to move the Fedora versions at the same speed that the upstream community is moving? Why? Should this problem be solved in Fedora or in the application (redmine upstream)? How can a package maintainer help?
Hi Emanuel,
I applaud your efforts to get Redmine packaged and included in Fedora proper.
Yes, there may be problems with Rails 3 being dropped and Redmine not being supported on Rails 4.
The goal here (in the Fedora realm) is supposed to be to make it work, rather than have it work rightout, and have people collaborate in making it so, rather than ship some sort of ideal SOHO server platform - and that's the spirit. If you're willing to take on Redmine compability with Rails (with help of others), and leave Rails free to move from one compatible version to some incompatible version, I see no problem.
I'm looking forward to the EPEL packages ;-)
Kind regards,
Jeroen van Meeuwen
----- Original Message -----
Replying to list to get wider discussion.
Posted by Bohuslav "Slavek" Kabrda on 2012-07-13 04:21:44 EDT to https://bugzilla.redhat.com/show_bug.cgi?id=825495 [Review Request: redmine]
Emanuel, I'm not sure we want redmine in Fedora. It would make us always have its specified version of rails. I don't think we want to have our hands tied with that. What if we want to get rails 4 (when they get released) into Fedora and redmine still relies on 3.2.3? This would limit us greatly, I have to say I am against that.
A solution to your problem might be creating a software collection [1], [2], which would be independent on system Gems versions. Unfortunately, software collections are n ot allowed into Fedora [3] - but I believe that if enough users would want to use them for projects like this, FPC would allow them. Redmine is a great candidate for a software collection, I think
[1] http://docs.fedoraproject.org/en-US/Fedora_Contributor_Documentation/1/html/... [2] https://fedorahosted.org/SoftwareCollections/ [3] https://fedoraproject.org/wiki/Packaging:Guidelines#Software_Collection_Macr...
What I want to achieve with this redmine package is:
- a high quality package by getting feedback from the community
- an easy installation with sane defaults for redmine users
A software collection goes part of the way there, but has some disadvantages by not being a first class citizen of Fedora.
When the rails community drops support for rails version 3, it should not be wise to still run Redmine installations for rails 3. At that time, we should work with upstream to make redmine work on rails 4.
When rails 4 is released but rails 3 is still supported, I see no reason why we could not have rails 3 and rails 4 side by side in Fedora. We do it for packages like python too.
Do you think having redmine in Fedora would limit your freedom to move the Fedora versions at the same speed that the upstream community is moving? Why? Should this problem be solved in Fedora or in the application (redmine upstream)? How can a package maintainer help?
Thank you for your comment,
Emanuel
Here is my concern: Will you ship redmine with Gemfile.lock? No: - User will run bundle install, that will install all the newest versions from rubygems.org, not caring about older versions installed by RPM. Result: redmine runs (by estimate) on half of RPM gems, half of non-RPM gems. Yes: - Gemfile.lock will contain circa 100 gems with precise versions. If any of these gems gets updated (even the tiny version), redmine has to be rebuilt to reflect this in a new Gemfile.lock, otherwise it will not work - or the user will delete Gemfile.lock and run bundle install.
So from my POV, you either have redmine running on half of non-RPM gems (why even package it then?) or a brutal dependency hell. Don't get me wrong, I'm not against getting this kind of packages into Fedora (quite on the contrary), but I really see no sane/supportable way to get redmine packaged ATM. Feel free to slap me with a stinking trout if you don't agree :)
On 07/18/2012 12:02 PM, Bohuslav Kabrda wrote:
Will you ship redmine with Gemfile.lock? No:
- User will run bundle install, that will install all the newest
versions from rubygems.org, not caring about older versions installed by RPM. Result: redmine runs (by estimate) on half of RPM gems, half of non-RPM gems.
another option (like we do for foreman packaging [1]) is to not to ship the lock file, but run bundler install --local in the post transaction section of the rpm.
Ohad [1] - http://yum.theforeman.org/development/ [2] - https://github.com/theforeman/foreman-rpms
----- Original Message -----
On 07/18/2012 12:02 PM, Bohuslav Kabrda wrote:
Will you ship redmine with Gemfile.lock? No:
- User will run bundle install, that will install all the newest
versions from rubygems.org, not caring about older versions installed by RPM. Result: redmine runs (by estimate) on half of RPM gems, half of non-RPM gems.
another option (like we do for foreman packaging [1]) is to not to ship the lock file, but run bundler install --local in the post transaction section of the rpm.
Ohad [1] - http://yum.theforeman.org/development/ [2] - https://github.com/theforeman/foreman-rpms
That still doesn't solve the issue, I think: 1) redmine requires rubygem-foo 2) user installs redmine, rpm runs "bundle install --local" and locks the currently installed version 3) in the meantime, rubygem-foo gets updated to newer version 4) user installs newer version of rubygem-foo (which uninstalls older version of rubygem-foo) 5) redmine's Gemfile.lock is broken
Yet I agree that we should follow this way, it seems like a good approach to me.
On 07/18/2012 08:30 AM, Bohuslav Kabrda wrote:
----- Original Message -----
On 07/18/2012 12:02 PM, Bohuslav Kabrda wrote:
Will you ship redmine with Gemfile.lock? No:
- User will run bundle install, that will install all the newest
versions from rubygems.org, not caring about older versions installed by RPM. Result: redmine runs (by estimate) on half of RPM gems, half of non-RPM gems.
another option (like we do for foreman packaging [1]) is to not to ship the lock file, but run bundler install --local in the post transaction section of the rpm.
Ohad [1] - http://yum.theforeman.org/development/ [2] - https://github.com/theforeman/foreman-rpms
That still doesn't solve the issue, I think:
- redmine requires rubygem-foo
- user installs redmine, rpm runs "bundle install --local" and locks the currently installed version
- in the meantime, rubygem-foo gets updated to newer version
- user installs newer version of rubygem-foo (which uninstalls older version of rubygem-foo)
- redmine's Gemfile.lock is broken
Well if redmine is dependent on a sepecific version of foo, it should be listed in the rpm dependencies, and thus yum should not allow you to update foo due to dependency issues correct?
-Mo
On Wed, Jul 18, 2012 at 11:02 AM, Bohuslav Kabrda bkabrda@redhat.com wrote:
Replying to list to get wider discussion.
Posted by Bohuslav "Slavek" Kabrda on 2012-07-13 04:21:44 EDT to https://bugzilla.redhat.com/show_bug.cgi?id=825495 [Review Request: redmine]
Emanuel, I'm not sure we want redmine in Fedora. It would make us always have its specified version of rails. I don't think we want to have our hands tied with that. What if we want to get rails 4 (when they get released) into Fedora and redmine still relies on 3.2.3? This would limit us greatly, I have to say I am against that.
A solution to your problem might be creating a software collection [1], [2], which would be independent on system Gems versions. Unfortunately, software collections are not allowed into Fedora [3] - but I believe that if enough users would want to use them for projects like this, FPC would allow them. Redmine is a great candidate for a software collection, I think
[1] http://docs.fedoraproject.org/en-US/Fedora_Contributor_Documentation/1/html/... [2] https://fedorahosted.org/SoftwareCollections/ [3] https://fedoraproject.org/wiki/Packaging:Guidelines#Software_Collection_Macr...
What I want to achieve with this redmine package is:
- a high quality package by getting feedback from the community
- an easy installation with sane defaults for redmine users
A software collection goes part of the way there, but has some disadvantages by not being a first class citizen of Fedora.
When the rails community drops support for rails version 3, it should not be wise to still run Redmine installations for rails 3. At that time, we should work with upstream to make redmine work on rails 4.
When rails 4 is released but rails 3 is still supported, I see no reason why we could not have rails 3 and rails 4 side by side in Fedora. We do it for packages like python too.
Do you think having redmine in Fedora would limit your freedom to move the Fedora versions at the same speed that the upstream community is moving? Why? Should this problem be solved in Fedora or in the application (redmine upstream)? How can a package maintainer help?
Thank you for your comment,
Emanuel
Here is my concern: Will you ship redmine with Gemfile.lock? No:
- User will run bundle install, that will install all the newest versions
from rubygems.org, not caring about older versions installed by RPM. Result: redmine runs (by estimate) on half of RPM gems, half of non-RPM gems. Yes:
- Gemfile.lock will contain circa 100 gems with precise versions. If any
of these gems gets updated (even the tiny version), redmine has to be rebuilt to reflect this in a new Gemfile.lock, otherwise it will not work - or the user will delete Gemfile.lock and run bundle install.
So from my POV, you either have redmine running on half of non-RPM gems (why even package it then?) or a brutal dependency hell. Don't get me wrong, I'm not against getting this kind of packages into Fedora (quite on the contrary), but I really see no sane/supportable way to get redmine packaged ATM. Feel free to slap me with a stinking trout if you don't agree :)
I have simply moved the gemfile out of the way (renamed into gemfile.orig) and let redmine load system libraries without using bundler. If this is a serious mistake - please do tell. The current work in progress package works perfectly using gems from Fedora repository. No dependencies are downloaded separately. The exception is Rails 3.2.3 for which I have made a stopgap rpm package until Rails 3.2.3 is in Fedora - but it also is installed via rpm. If the user installs an incompatible version using the 'gem' command himself, outside of Fedora package management, redmine could of course break. I am not sure how to prevent that. Hopefully the user would not override system libraries like that.
On 07/18/2012 08:40 AM, Emanuel Rietveld wrote:
On Wed, Jul 18, 2012 at 11:02 AM, Bohuslav Kabrda bkabrda@redhat.com wrote:
Replying to list to get wider discussion.
Posted by Bohuslav "Slavek" Kabrda on 2012-07-13 04:21:44 EDT to https://bugzilla.redhat.com/show_bug.cgi?id=825495 [Review Request: redmine]
Emanuel, I'm not sure we want redmine in Fedora. It would make us always have its specified version of rails. I don't think we want to have our hands tied with that. What if we want to get rails 4 (when they get released) into Fedora and redmine still relies on 3.2.3? This would limit us greatly, I have to say I am against that.
A solution to your problem might be creating a software collection [1], [2], which would be independent on system Gems versions. Unfortunately, software collections are not allowed into Fedora [3] - but I believe that if enough users would want to use them for projects like this, FPC would allow them. Redmine is a great candidate for a software collection, I think [1] http://docs.fedoraproject.org/en-US/Fedora_Contributor_Documentation/1/html/... [2] https://fedorahosted.org/SoftwareCollections/ [3] https://fedoraproject.org/wiki/Packaging:Guidelines#Software_Collection_Macr...
What I want to achieve with this redmine package is:
- a high quality package by getting feedback from the community
- an easy installation with sane defaults for redmine users
A software collection goes part of the way there, but has some disadvantages by not being a first class citizen of Fedora.
When the rails community drops support for rails version 3, it should not be wise to still run Redmine installations for rails 3. At that time, we should work with upstream to make redmine work on rails 4.
When rails 4 is released but rails 3 is still supported, I see no reason why we could not have rails 3 and rails 4 side by side in Fedora. We do it for packages like python too.
Do you think having redmine in Fedora would limit your freedom to move the Fedora versions at the same speed that the upstream community is moving? Why? Should this problem be solved in Fedora or in the application (redmine upstream)? How can a package maintainer help?
Thank you for your comment,
Emanuel
Here is my concern: Will you ship redmine with Gemfile.lock? No:
- User will run bundle install, that will install all the newest versions
from rubygems.org, not caring about older versions installed by RPM. Result: redmine runs (by estimate) on half of RPM gems, half of non-RPM gems. Yes:
- Gemfile.lock will contain circa 100 gems with precise versions. If any
of these gems gets updated (even the tiny version), redmine has to be rebuilt to reflect this in a new Gemfile.lock, otherwise it will not work - or the user will delete Gemfile.lock and run bundle install.
So from my POV, you either have redmine running on half of non-RPM gems (why even package it then?) or a brutal dependency hell. Don't get me wrong, I'm not against getting this kind of packages into Fedora (quite on the contrary), but I really see no sane/supportable way to get redmine packaged ATM. Feel free to slap me with a stinking trout if you don't agree :)
I have simply moved the gemfile out of the way (renamed into gemfile.orig) and let redmine load system libraries without using bundler. If this is a serious mistake - please do tell. The current work in progress package works perfectly using gems from Fedora repository. No dependencies are downloaded separately. The exception is Rails 3.2.3 for which I have made a stopgap rpm package until Rails 3.2.3 is in Fedora - but it also is installed via rpm. If the user installs an incompatible version using the 'gem' command himself, outside of Fedora package management, redmine could of course break. I am not sure how to prevent that. Hopefully the user would not override system libraries like that.
Yes, jayg (cc'd) has been doing some work with regard to getting bundler to work with system libraries (eg those installed via rpm), not sure if his efforts would be able to assist you.
In any case, you can leverage the 'gem' method in addition to requiring the modules in redmine to require specific versions of the packages you depend on. That way even if a user installs an alternate version via the gem command, the system library will be used.
-Mo
----- Original Message -----
On 07/18/2012 08:40 AM, Emanuel Rietveld wrote:
On Wed, Jul 18, 2012 at 11:02 AM, Bohuslav Kabrda bkabrda@redhat.com wrote:
Replying to list to get wider discussion.
Posted by Bohuslav "Slavek" Kabrda on 2012-07-13 04:21:44 EDT to https://bugzilla.redhat.com/show_bug.cgi?id=825495 [Review Request: redmine]
Emanuel, I'm not sure we want redmine in Fedora. It would make us always have its specified version of rails. I don't think we want to have our hands tied with that. What if we want to get rails 4 (when they get released) into Fedora and redmine still relies on 3.2.3? This would limit us greatly, I have to say I am against that.
A solution to your problem might be creating a software collection [1], [2], which would be independent on system Gems versions. Unfortunately, software collections are not allowed into Fedora [3] - but I believe that if enough users would want to use them for projects like this, FPC would allow them. Redmine is a great candidate for a software collection, I think [1] http://docs.fedoraproject.org/en-US/Fedora_Contributor_Documentation/1/html/... [2] https://fedorahosted.org/SoftwareCollections/ [3] https://fedoraproject.org/wiki/Packaging:Guidelines#Software_Collection_Macr...
What I want to achieve with this redmine package is:
- a high quality package by getting feedback from the community
- an easy installation with sane defaults for redmine users
A software collection goes part of the way there, but has some disadvantages by not being a first class citizen of Fedora.
When the rails community drops support for rails version 3, it should not be wise to still run Redmine installations for rails 3. At that time, we should work with upstream to make redmine work on rails 4.
When rails 4 is released but rails 3 is still supported, I see no reason why we could not have rails 3 and rails 4 side by side in Fedora. We do it for packages like python too.
Do you think having redmine in Fedora would limit your freedom to move the Fedora versions at the same speed that the upstream community is moving? Why? Should this problem be solved in Fedora or in the application (redmine upstream)? How can a package maintainer help?
Thank you for your comment,
Emanuel
Here is my concern: Will you ship redmine with Gemfile.lock? No:
- User will run bundle install, that will install all the newest
versions from rubygems.org, not caring about older versions installed by RPM. Result: redmine runs (by estimate) on half of RPM gems, half of non-RPM gems. Yes:
- Gemfile.lock will contain circa 100 gems with precise versions.
If any of these gems gets updated (even the tiny version), redmine has to be rebuilt to reflect this in a new Gemfile.lock, otherwise it will not work - or the user will delete Gemfile.lock and run bundle install.
So from my POV, you either have redmine running on half of non-RPM gems (why even package it then?) or a brutal dependency hell. Don't get me wrong, I'm not against getting this kind of packages into Fedora (quite on the contrary), but I really see no sane/supportable way to get redmine packaged ATM. Feel free to slap me with a stinking trout if you don't agree :)
I have simply moved the gemfile out of the way (renamed into gemfile.orig) and let redmine load system libraries without using bundler. If this is a serious mistake - please do tell. The current work in progress package works perfectly using gems from Fedora repository. No dependencies are downloaded separately. The exception is Rails 3.2.3 for which I have made a stopgap rpm package until Rails 3.2.3 is in Fedora - but it also is installed via rpm. If the user installs an incompatible version using the 'gem' command himself, outside of Fedora package management, redmine could of course break. I am not sure how to prevent that. Hopefully the user would not override system libraries like that.
Yes, jayg (cc'd) has been doing some work with regard to getting bundler to work with system libraries (eg those installed via rpm), not sure if his efforts would be able to assist you.
In any case, you can leverage the 'gem' method in addition to requiring the modules in redmine to require specific versions of the packages you depend on. That way even if a user installs an alternate version via the gem command, the system library will be used.
Well, yes. But then again, we're attaching ourselves to having that precise version in Fedora. And then imagine that you have e.g. 5 projects like redmine, each relying on a specific (different) version or rubygem-foo. So we will maintain 5 versions of rubygem-foo? What I mean by this is, that we should do two general things: 1) Deal with bundler so that users can easily use system gems if they choose to (yes, it's that discussion again) - Removing Gemfile might just work, if the packager makes sure that everything works afterwards (which is a big if). I'm curious what jayg has to say here. I myself have recently tried to talk to bundler upstream with no good result [1], [2]. They have their good points, but they just refuse to see our ones, that might be valid as well. 2) Encourage Ruby community not to rely on one specific version of something, but rather cooperate with wider variety of versions - I'm just not sure how to manage that :)
Redmine is probably just a good starter for this discussion, as it shows these symptoms that we have to deal with.
-Mo
[1] https://github.com/carlhuda/bundler/issues/1964 [2] https://github.com/carlhuda/bundler/issues/2004
On Thu, Jul 19, 2012 at 7:37 AM, Bohuslav Kabrda bkabrda@redhat.com wrote:
----- Original Message -----
On 07/18/2012 08:40 AM, Emanuel Rietveld wrote:
On Wed, Jul 18, 2012 at 11:02 AM, Bohuslav Kabrda bkabrda@redhat.com wrote:
Replying to list to get wider discussion.
Posted by Bohuslav "Slavek" Kabrda on 2012-07-13 04:21:44 EDT to https://bugzilla.redhat.com/show_bug.cgi?id=825495 [Review Request: redmine]
Emanuel, I'm not sure we want redmine in Fedora. It would make us always have its specified version of rails. I don't think we want to have our hands tied with that. What if we want to get rails 4 (when they get released) into Fedora and redmine still relies on 3.2.3? This would limit us greatly, I have to say I am against that.
A solution to your problem might be creating a software collection [1], [2], which would be independent on system Gems versions. Unfortunately, software collections are not allowed into Fedora [3] - but I believe that if enough users would want to use them for projects like this, FPC would allow them. Redmine is a great candidate for a software collection, I think [1] http://docs.fedoraproject.org/en-US/Fedora_Contributor_Documentation/1/html/... [2] https://fedorahosted.org/SoftwareCollections/ [3] https://fedoraproject.org/wiki/Packaging:Guidelines#Software_Collection_Macr...
What I want to achieve with this redmine package is:
- a high quality package by getting feedback from the community
- an easy installation with sane defaults for redmine users
A software collection goes part of the way there, but has some disadvantages by not being a first class citizen of Fedora.
When the rails community drops support for rails version 3, it should not be wise to still run Redmine installations for rails 3. At that time, we should work with upstream to make redmine work on rails 4.
When rails 4 is released but rails 3 is still supported, I see no reason why we could not have rails 3 and rails 4 side by side in Fedora. We do it for packages like python too.
Do you think having redmine in Fedora would limit your freedom to move the Fedora versions at the same speed that the upstream community is moving? Why? Should this problem be solved in Fedora or in the application (redmine upstream)? How can a package maintainer help?
Thank you for your comment,
Emanuel
Here is my concern: Will you ship redmine with Gemfile.lock? No:
- User will run bundle install, that will install all the newest
versions from rubygems.org, not caring about older versions installed by RPM. Result: redmine runs (by estimate) on half of RPM gems, half of non-RPM gems. Yes:
- Gemfile.lock will contain circa 100 gems with precise versions.
If any of these gems gets updated (even the tiny version), redmine has to be rebuilt to reflect this in a new Gemfile.lock, otherwise it will not work - or the user will delete Gemfile.lock and run bundle install.
So from my POV, you either have redmine running on half of non-RPM gems (why even package it then?) or a brutal dependency hell. Don't get me wrong, I'm not against getting this kind of packages into Fedora (quite on the contrary), but I really see no sane/supportable way to get redmine packaged ATM. Feel free to slap me with a stinking trout if you don't agree :)
I have simply moved the gemfile out of the way (renamed into gemfile.orig) and let redmine load system libraries without using bundler. If this is a serious mistake - please do tell. The current work in progress package works perfectly using gems from Fedora repository. No dependencies are downloaded separately. The exception is Rails 3.2.3 for which I have made a stopgap rpm package until Rails 3.2.3 is in Fedora - but it also is installed via rpm. If the user installs an incompatible version using the 'gem' command himself, outside of Fedora package management, redmine could of course break. I am not sure how to prevent that. Hopefully the user would not override system libraries like that.
Yes, jayg (cc'd) has been doing some work with regard to getting bundler to work with system libraries (eg those installed via rpm), not sure if his efforts would be able to assist you.
In any case, you can leverage the 'gem' method in addition to requiring the modules in redmine to require specific versions of the packages you depend on. That way even if a user installs an alternate version via the gem command, the system library will be used.
Well, yes. But then again, we're attaching ourselves to having that precise version in Fedora. And then imagine that you have e.g. 5 projects like redmine, each relying on a specific (different) version or rubygem-foo. So we will maintain 5 versions of rubygem-foo? What I mean by this is, that we should do two general things:
- Deal with bundler so that users can easily use system gems if they choose to (yes, it's that discussion again) - Removing Gemfile might just work, if the packager makes sure that everything works afterwards (which is a big if). I'm curious what jayg has to say here. I myself have recently tried to talk to bundler upstream with no good result [1], [2]. They have their good points, but they just refuse to see our ones, that might be valid as well.
- Encourage Ruby community not to rely on one specific version of something, but rather cooperate with wider variety of versions - I'm just not sure how to manage that :)
Redmine is probably just a good starter for this discussion, as it shows these symptoms that we have to deal with.
-Mo
[1] https://github.com/carlhuda/bundler/issues/1964 [2] https://github.com/carlhuda/bundler/issues/2004
1. I've been following the discussion about bundler and system libraries with interest. On my Fedora 17 and 18 systems, I have applied a small patch to get bundler to call spec.activate on the gem instead of using its own method of activating gems, and since then bundler has loaded all system gems (installed with rpm) without issue. Despite that, I have chosen not to use bundler for redmine, because it was easier. I don't think it would be much trouble to use it, provided that small patch could be applied to Fedora bundler.
2. So let's say you want to update one of the dependencies of redmine - rubygem-foo - to 1.2.3 but redmine still relies on rubygem-foo 1.1. In the old world of software, you would say that rubygem-foo 1.1 is no longer supported by vendor and that we should upgrade all our software to work with the supported version instead. So, we would work with redmine upstream to make redmine compatible with rubygem-foo 1.1.
There are a couple of concerns:
- The ruby world moves very fast, and api-breaking updates to libraries are released regularly. Support for older versions is dropped very quickly. This means high workload. - The time it takes to get redmine compatible with the new version of rubygem-foo might be longer than you are willing to wait to update rubygem-foo.
The simplest thing to do is to have both versions concurrently, perhaps vendored with the application. That is what the ruby world is largely doing.
The right thing to do is to work hard, track development of all dependency relationships on Fedora (perhaps responsibility of package maintainer), know when api-breaking changes are going to happen and work with upstreams as early as possible to move them over to the new version.
If we choose the simple way, it would lead to proliferation of gem versions in Fedora and a very high support burden. If we choose the right way, it would be a very high maintenance burden on the package maintainers of ruby applications and ruby gems.
Those problems are inherent in the way the ruby world works.
One other "solution" is not to bother with ruby applications in Fedora and just - I don't know - make a gem out of the applications or something and ask users to just gem install it. I do not care much for this solution. This moves all the workload to system administrators and users.
Emanuel
Dne 19.7.2012 09:51, Emanuel Rietveld napsal(a):
- I've been following the discussion about bundler and system
libraries with interest. On my Fedora 17 and 18 systems, I have applied a small patch to get bundler to call spec.activate on the gem instead of using its own method of activating gems, and since then bundler has loaded all system gems (installed with rpm) without issue. Despite that, I have chosen not to use bundler for redmine, because it was easier. I don't think it would be much trouble to use it, provided that small patch could be applied to Fedora bundler.
Hm, I saw that patch somewehere, but it was probably incompatible with older RubyGems, therefore not applicable for Bundler. On the other hand, there is plenty RubyGems version specific hacks, so that might be another one.
The right thing to do is to work hard, track development of all dependency relationships on Fedora (perhaps responsibility of package maintainer), know when api-breaking changes are going to happen and work with upstreams as early as possible to move them over to the new version.
I like this scenario, but who will do that? If you volunteer, then there is no problem :) But it means that you will become more or less Redmine developer.
Vit
On Thu, Jul 19, 2012 at 2:14 PM, Vít Ondruch vondruch@redhat.com wrote:
Dne 19.7.2012 09:51, Emanuel Rietveld napsal(a):
- I've been following the discussion about bundler and system libraries
with interest. On my Fedora 17 and 18 systems, I have applied a small patch to get bundler to call spec.activate on the gem instead of using its own method of activating gems, and since then bundler has loaded all system gems (installed with rpm) without issue. Despite that, I have chosen not to use bundler for redmine, because it was easier. I don't think it would be much trouble to use it, provided that small patch could be applied to Fedora bundler.
Hm, I saw that patch somewehere, but it was probably incompatible with older RubyGems, therefore not applicable for Bundler. On the other hand, there is plenty RubyGems version specific hacks, so that might be another one.
This was the patch. I expect it to change nothing on rubygems versions older than 1.8, where spec.activate was introduced. In my humble opinion, calling into rubygems to activate gems has some advantages over duplicating the gem activation code in bundler. For Fedora, the main advantage is that bundler activates rpm installed gems correctly.
diff --git a/lib/bundler/runtime.rb b/lib/bundler/runtime.rb index 52e3dc6..8683cf7 100644 --- a/lib/bundler/runtime.rb +++ b/lib/bundler/runtime.rb @@ -31,9 +31,13 @@ module Bundler raise e end
- Bundler.rubygems.mark_loaded(spec) - load_paths = spec.load_paths.reject {|path| $LOAD_PATH.include?(path)} - $LOAD_PATH.unshift(*load_paths) + if spec.respond_to?(:activate) + spec.activate + else + Bundler.rubygems.mark_loaded(spec) + load_paths = spec.load_paths.reject {|path| $LOAD_PATH.include?(path)} + $LOAD_PATH.unshift(*load_paths) + end end
lock
The right thing to do is to work hard, track development of all dependency relationships on Fedora (perhaps responsibility of package maintainer), know when api-breaking changes are going to happen and work with upstreams as early as possible to move them over to the new version.
I like this scenario, but who will do that? If you volunteer, then there is no problem :) But it means that you will become more or less Redmine developer.
Vit
And what about packaging guidelines? Will we refuse to accept packages into Fedora unless the package maintainer assumes that responsibility? What if I accept the responsibility, but am slow to update redmine (I'm a volunteer after all). Does that block the update of rubygem-foo until I get around to it? Do we only update gems in rawhide? Do we allow unresolvable dependencies in released Fedora versions? Do we keep two versions of rubygem-foo in Fedora for the mean time?
Emanuel
On Thu, Jul 19, 2012 at 6:47 AM, Emanuel Rietveld codehotter@gmail.com wrote:
Do we only update gems in rawhide?
Well, it seems like this is what Gem maintainers has been doing, at least for the Fedora 17 cycle. Although, it seems to have been based on necessity (given the large amount of upstream churn) rather than an ad-hoc Fedora policy :)
- Ken
ruby-sig@lists.fedoraproject.org
-
Bohuslav Kabrda -
Emanuel Rietveld -
Jeroen van Meeuwen -
Ken Dreyer -
Mo Morsi -
Ohad Levy -
Vít Ondruch