Bug 825495

when I worked on separation of 3rd party code outside, i have noticed that some of that is no longer supported by upstream (for example rfpdf, last commit in 2006, upstream web site no longer exists, etc..)
also classic_pagination was deprecated by upstream 2 years ago
in this cases, you would need to act as upstream when you will split those libraries into separate package.
i suggest that you consider packaging ChiliProject (fork of redmine) due to wider development support (you are more likely to convince them to abandon classsic_pagination and replace it with will_paginate, or other necessary code changes)

*** Bug 499959 has been marked as a duplicate of this bug. ***

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

(In reply to Bohuslav "Slavek" Kabrda from comment #3)
> 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.

I don't think it's right decision to ban redmine from Fedora because it's upstream doesn't port it to the latest rails immediately after it gets released. I'm not ruby/rails expert but in my opinion situation when redmine (or other rails project) depends on older rails and you want new rails in distro before redmine gets ported, you can create rails-compat package with old rails and update the main rails pkg. There are many examples of this approach in distro (gtk2/gtk3, qt3/qt and various .*compat.* packages with their latest counterparts). Or is not possible to have two packages of rails same time in Fedora without package collections?

Nobody bans Redmine. We only lack the menpower. We are speaking here about up to 50+- packages which needs to be maintained.

(In reply to Vít Ondruch from comment #5)
> Nobody bans Redmine. We only lack the menpower. We are speaking here about
> up to 50+- packages which needs to be maintained.

If I understand correctly, maintaining two versions of rails simultaneously means maintaining rails and additional 49 compat packages? Or you meant that redmine will require additional 50+- packages in distro?

The core of RoR consist of 8 packages. However, these packages has another dependencies and enforces their specific versions. You can start with RDoc, continue with minitest, sprockets, etc.

Hello, a security flaw in redmine was reported:

http://seclists.org/oss-sec/2014/q2/18

If redmine is released in Fedora, could that fix please be included?

Thanks,

--
Murray McAllister / Red Hat Security Response Team

Hi,

Redmine isn't release in Fedora.

Best regard