Spec URL: http://xls01.freecult.org/pkg/?p=pkg.git;a=blob_plain;f=SPECS/redmine.spec;hb=redmine
SRPM URL: http://xls01.freecult.org/pkg/?p=pkg.git;a=blob_plain;f=SRPMS/redmine-2.0.0-1.fc18.src.rpm;hb=redmine
Fedora Account System Username: codehotter
Redmine has been submitted for review previously
That review has been abandoned.
At the time of writing, while package builds in mock and does work, this package is really not ready for inclusion in Fedora. I want to submit it anyway to hopefully get some comments and some help. These are currently the main issues:
- Fedora 18 does not yet have rubygem-rails 3.2.3 which redmine requires.
- Redmine bundles 3rd party code
- rpmlint is far from silent. I really have no idea what is safe for me to fix and what isn't, and frankly I'm a bit overwhelmed by the amount of errors.
- Redmine needs an application server to run under, the most common of which is passenger. At the time of writing, rubygem-passenger is still under review for Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=470696
If you have ideas to fix some of the rpmlint errors and unbundle the 3rd party software redmine bundles, I could use your help.
I have written a README.fedora and a redmine-setup script to help new users install redmine on fedora. I would much appreciate it if you could look these over and see if they are OK. This is first time I've written a readme or an installation script for Fedora.
Of course I will keep working on this. As I update the git repo, the links in this post should stay current. They link to the latest version.
The rubygem-rails-3.2.3 rpms that you can find by clicking on the 'tree' link are fake - completely not compliant with packaging guidelines. I have used those rpms as a stopgap solution to continue working on redmine until rails 3.2.3 is in Fedora 18.
Thank you for your time.
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. ***
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 , , which would be independent on system Gems versions. Unfortunately, software collections are not allowed into Fedora  - 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.
(In reply to Bohuslav "Slavek" Kabrda from comment #3)
> 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 , ,
> which would be independent on system Gems versions. Unfortunately, software
> collections are not allowed into Fedora  - 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:
If redmine is released in Fedora, could that fix please be included?
Murray McAllister / Red Hat Security Response Team
Redmine isn't release in Fedora.