On 07/18/2012 08:40 AM, Emanuel Rietveld wrote:
> On Wed, Jul 18, 2012 at 11:02 AM, Bohuslav Kabrda
> <bkabrda(a)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/ht...
>>> [2]
https://fedorahosted.org/SoftwareCollections/
>>> [3]
>>>
https://fedoraproject.org/wiki/Packaging:Guidelines#Software_Collection_M...
>> 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.