On Wed, Jul 18, 2012 at 11:02 AM, Bohuslav Kabrda <[email protected]> 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 > > [2] https://fedorahosted.org/SoftwareCollections/ > > [3] > > https://fedoraproject.org/wiki/Packaging:Guidelines#Software_Collection_Macros > > 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. _______________________________________________ ruby-sig mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
