Redmine in Fedora?

Emanuel Rietveld codehotter at gmail.com
Wed Jul 18 12:40:38 UTC 2012


On Wed, Jul 18, 2012 at 11:02 AM, Bohuslav Kabrda <bkabrda at 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/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.


More information about the ruby-sig mailing list