Hi,
we are using redmine as our project management tool and installation and maintenance is a bit cumbersome. Having a Fedora package would make it a lot easier. Has someone already tried to create a Fedora package of Redmine? Or are there specific issues that make it difficult to create a rpm?
I'm wondering that no rpm distribution includes a Redmine package. There is a third party package, but it is non-functional.
Thanks Peter
Hi Peter,
I have not heard about Redmine packaging for ages.
I think that the problem is typically the amount of dependencies, but probably mainly the compatibility. If Redmine is built on top of Rails, it is using some specific version. So having Redmine in Fedora would likely block update of Rails. Just looking at GH, it seems that while the development version is using Rails 6.1.4.4, we have already Rails 7.0, but the stable version is using Rails 5.2.
With some bundling, that would be probably doable, but so far nobody picked up the ball.
Vít
Dne 28. 01. 22 v 10:31 Peter Boy napsal(a):
Hi,
we are using redmine as our project management tool and installation and maintenance is a bit cumbersome. Having a Fedora package would make it a lot easier. Has someone already tried to create a Fedora package of Redmine? Or are there specific issues that make it difficult to create a rpm?
I'm wondering that no rpm distribution includes a Redmine package. There is a third party package, but it is non-functional.
Thanks Peter _______________________________________________ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.o... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Redmine is very configurable. Might it be possible to automate deployment, for example with Ansible, Puppet or other similar tools? This may be easier to use for your purposes.
On 1/28/22 2:01 PM, Vít Ondruch wrote:
Hi Peter,
I have not heard about Redmine packaging for ages.
I think that the problem is typically the amount of dependencies, but probably mainly the compatibility. If Redmine is built on top of Rails, it is using some specific version. So having Redmine in Fedora would likely block update of Rails. Just looking at GH, it seems that while the development version is using Rails 6.1.4.4, we have already Rails 7.0, but the stable version is using Rails 5.2.
With some bundling, that would be probably doable, but so far nobody picked up the ball.
Vít
Dne 28. 01. 22 v 10:31 Peter Boy napsal(a):
Hi,
we are using redmine as our project management tool and installation and maintenance is a bit cumbersome. Having a Fedora package would make it a lot easier. Has someone already tried to create a Fedora package of Redmine? Or are there specific issues that make it difficult to create a rpm?
I'm wondering that no rpm distribution includes a Redmine package. There is a third party package, but it is non-functional.
Thanks Peter _______________________________________________ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.o...
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.o... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Hi,
Redmine is very configurable. Might it be possible to automate deployment, for example with Ansible, Puppet or other similar tools? This may be easier to use for your purposes.
On 1/28/22 2:01 PM, Vít Ondruch wrote:
installation currently requires a lot of development tools, including gcc (needed for native components of some gems). And I don't like development tools on a production server (well, I could uninstall the development tools afterwards as part of Ansible playbook, hm).
Dne 28. 01. 22 v 14:10 Peter Boy napsal(a):
Hi,
Redmine is very configurable. Might it be possible to automate deployment, for example with Ansible, Puppet or other similar tools? This may be easier to use for your purposes.
On 1/28/22 2:01 PM, Vít Ondruch wrote:
installation currently requires a lot of development tools, including gcc (needed for native components of some gems). And I don't like development tools on a production server (well, I could uninstall the development tools afterwards as part of Ansible playbook, hm).
I have the same view (I don't have gcc on my computer, just FYI), therefore I always use as many system gems as possible and combining with their upstream versions where necessary. So if there was some additional gem with binary extension needed, I'd probably opt to package it for Fedora.
Vít
Hi Vit,
thanks for the info. I'm still considering packaging Redmine. There are not so many, really free project management software options. Personally, I never did development in Ruby, but a student of mine is a big Ruby fan. So the Ruby side is doable.
I don't want to take up too much of your time, but regarding the Fedora side, I would probably need information. Currently, I have 2 questions:
Current Redmine requires Ruby 2.7. It’s a module in Fedora 35. As a module, it must not be installed in parallel with current 3.0 (or 3.1 in F36). So, would a Redmine package restrict the complete installation to Ruby 2.7? Or would conflict with other Ruby programs or development environments? (In Java, we install several JVM versions in parallel and each program can pick a fitting one).
In Java there are a lot of dependency (and version) issues, too. This leads to quite elaborate spec files and version tracking, and a lot of work. So I'm used to it to some extent.
Redmine 4.2 needs rails 5.2, indeed. And in gemfile there are mostly very specific version specifications, likely as outdated as rails is. If I understand bundler correctly, I can store those gems in ~/vendor and make everything private to Redmine. Is that the proper way? Or what is the proper Fedora way?
Thanks Peter
On Fri, Jan 28, 2022 at 2:06 PM Peter Boy pboy@uni-bremen.de wrote:
Hi Vit,
thanks for the info. I'm still considering packaging Redmine. There are not so many, really free project management software options. Personally, I never did development in Ruby, but a student of mine is a big Ruby fan. So the Ruby side is doable.
Hello,
I can try building it in COPR[1], if you'd be interested in collaboration. I think it would be better to handle everything in COPR though (I'm the maintainer of RoR; building RoR in COPR regularly[2]). We can build it together with Rails (even with 6.1.x) in one repo, but only in F35[3] life-cycle, because F36 will have 7.0 already. Maybe it would be easier to maintain it for something like epel-8 or epel-9 (you can build that in COPR too), as there're no rails there (we can build those). But some manual/upstream Ruby fixes would be required.
[1] https://docs.pagure.org/copr.copr/user_documentation.html [2] https://copr.fedorainfracloud.org/coprs/pvalena/ruby-on-rails/ [3] https://src.fedoraproject.org/rpms/rubygem-rails/blob/f35/f/rubygem-rails.sp...
I don't want to take up too much of your time, but regarding the Fedora side, I would probably need information. Currently, I have 2 questions:
Current Redmine requires Ruby 2.7. It’s a module in Fedora 35. As a module, it must not be installed in parallel with current 3.0 (or 3.1 in F36). So, would a Redmine package restrict the complete installation to Ruby 2.7? Or would conflict with other Ruby programs or development environments? (In Java, we install several JVM versions in parallel and each program can pick a fitting one).
Ruby does not have parallel installations of Ruby, apart from modules. It itself would need to be packaged as a module (this can be done in COPR also). But from my experience compatibility across versions of Ruby (at least the latest ones) is quite good, so I would try running it with 3.0.
In Java there are a lot of dependency (and version) issues, too. This leads to quite elaborate spec files and version tracking, and a lot of work. So I'm used to it to some extent.
Redmine 4.2 needs rails 5.2, indeed. And in gemfile there are mostly very specific version specifications, likely as outdated as rails is. If I understand bundler correctly, I can store those gems in ~/vendor and make everything private to Redmine. Is that the proper way? Or what is the proper Fedora way?
Running it with Rails 5.2 would be possible, but in Fedora installing anything to ~/vendor goes against the packaging. The philosophy is to build all the dependencies that would be installed by bundler as RPMs instead. There's some level of automation, but the issue is maintainability and stability (running tests). If you're not interested in running the tests, the stability gets much worse, but it's much easier to maintain - so ideally there would be some balance; running in COPR is ideal for that, in the beginning at least - avoiding package reviews; all the tests fixes etc.. Also there's some overhead for maintaining modules (esp. bigger ones), so I'd prefer to avoid that.
Let me know if you're interested.
Regards, Pavel
Thanks Peter
Dne 28. 01. 22 v 16:18 Pavel Valena napsal(a):
On Fri, Jan 28, 2022 at 2:06 PM Peter Boy pboy@uni-bremen.de wrote:
Hi Vit,
thanks for the info. I'm still considering packaging Redmine. There are not so many, really free project management software options. Personally, I never did development in Ruby, but a student of mine is a big Ruby fan. So the Ruby side is doable.
Hello,
I can try building it in COPR[1], if you'd be interested in collaboration. I think it would be better to handle everything in COPR though (I'm the maintainer of RoR; building RoR in COPR regularly[2]). We can build it together with Rails (even with 6.1.x) in one repo, but only in F35[3] life-cycle, because F36 will have 7.0 already. Maybe it would be easier to maintain it for something like epel-8 or epel-9 (you can build that in COPR too), as there're no rails there (we can build those). But some manual/upstream Ruby fixes would be required.
[1] https://docs.pagure.org/copr.copr/user_documentation.html [2] https://copr.fedorainfracloud.org/coprs/pvalena/ruby-on-rails/ [3] https://src.fedoraproject.org/rpms/rubygem-rails/blob/f35/f/rubygem-rails.sp...
I don't want to take up too much of your time, but regarding the Fedora side, I would probably need information. Currently, I have 2 questions:
Current Redmine requires Ruby 2.7. It’s a module in Fedora 35. As a module, it must not be installed in parallel with current 3.0 (or 3.1 in F36). So, would a Redmine package restrict the complete installation to Ruby 2.7? Or would conflict with other Ruby programs or development environments? (In Java, we install several JVM versions in parallel and each program can pick a fitting one).
Ruby does not have parallel installations of Ruby, apart from modules. It itself would need to be packaged as a module (this can be done in COPR also). But from my experience compatibility across versions of Ruby (at least the latest ones) is quite good, so I would try running it with 3.0.
In Java there are a lot of dependency (and version) issues, too. This leads to quite elaborate spec files and version tracking, and a lot of work. So I'm used to it to some extent.
Redmine 4.2 needs rails 5.2, indeed. And in gemfile there are mostly very specific version specifications, likely as outdated as rails is. If I understand bundler correctly, I can store those gems in ~/vendor and make everything private to Redmine. Is that the proper way? Or what is the proper Fedora way?
Running it with Rails 5.2 would be possible, but in Fedora installing anything to ~/vendor goes against the packaging. The philosophy is to build all the dependencies that would be installed by bundler as RPMs instead.
I'd say this philosophy was overcome. While noble (and don't get me wrong, I very much like it and obey it whenever possible), that might be one of reasons why we don't have Redmine in Fedora.
So I believe that for this reason, the bundling policy was relaxed quite some time ago and it would be reasonable for this case, if used wisely. I.e.
* use as many system gems as possible and vendor only where inevitable and as a last resort
* make sure we strive to improve the compatibility and remove the need for bundling
BTW, bundle everything and remove incrementaly is also good start, because in the mean time, the incentive is working application. I have seen too many failures when everything was attempted to be unbundled from beginning.
Vít
Sorry for my late response! The mixture of weekend, time zones, children and corona are becoming a considerable challenge at times.
Am 28.01.2022 um 16:18 schrieb Pavel Valena pvalena@redhat.com: I can try building it in COPR[1], if you'd be interested in collaboration.
I am very interested in cooperation and would appreciate it a lot! I could certainly learn a lot. I have developed in several programming languages, but never in Ruby. And I have built rpms, but never in the Fedora infrastructure.
I think it would be better to handle everything in COPR though (I'm the maintainer of RoR; building RoR in COPR regularly[2]). We can build it together with Rails (even with 6.1.x) in one repo, but only in F35[3] life-cycle, because F36 will have 7.0 already. Maybe it would be easier to maintain it for something like epel-8 or epel-9 (you can build that in COPR too), as there're no rails there (we can build those). But some manual/upstream Ruby fixes would be required.
As I get it, we would start in COPR with source rpm. I set up a tiny virtual machine on one of our public servers to create a shared available space to build Redmine and to create a first source rpm. I would be happy to send you the access data and my doc for it as PM. And maybe we can find a time between our time zones where we can talk via chat (I’m living in Germany, UTC+1). The VM is not there for anything else. So nothing can break.
Ruby does not have parallel installations of Ruby, apart from modules. It itself would need to be packaged as a module (this can be done in COPR also). But from my experience compatibility across versions of Ruby (at least the latest ones) is quite good, so I would try running it with 3.0.
I'm a bit hesitant to deviate from the upstream project specification for a production installation. The gemfile explicitly requires Ruby <=2.7x and Rails 5, even in the latest stable branch. And I would like to do this for Epel. As far as I know, a Ruby 2.x is used there.
In a next step an "early bird" version would be interesting, with Ruby 3 and either with the latest stable branch or even trunk.
We should try to contact the project what they are thinking ab that.
Running it with Rails 5.2 would be possible, but in Fedora installing anything to ~/vendor goes against the packaging. The philosophy is to build all the dependencies that would be installed by bundler as RPMs instead. There's some level of automation, but the issue is maintainability and stability (running tests). If you're not interested in running the tests, the stability gets much worse, but it's much easier to maintain - so ideally there would be some balance; running in COPR is ideal for that, in the beginning at least - avoiding package reviews; all the tests fixes etc.. Also there's some overhead for maintaining modules (esp. bigger ones), so I'd prefer to avoid that.
I know a similar problem from Java.
I have tried a little bit. A larger number of gems that are collected with bundler are also available with the 2.7 module as rpm. Unfortunately, especially rails and also red carpet (for Markdown wiki pages) are not. I’ll check in detail which gems are available as rpm and make a list. And then we would have to decide on the rest.
Let me know if you're interested.
Yes, I’m very much :-)
Best Peter
Dne 28. 01. 22 v 14:04 Peter Boy napsal(a):
Hi Vit,
thanks for the info. I'm still considering packaging Redmine. There are not so many, really free project management software options. Personally, I never did development in Ruby, but a student of mine is a big Ruby fan. So the Ruby side is doable.
I don't want to take up too much of your time, but regarding the Fedora side, I would probably need information. Currently, I have 2 questions:
Current Redmine requires Ruby 2.7. It’s a module in Fedora 35. As a module, it must not be installed in parallel with current 3.0 (or 3.1 in F36). So, would a Redmine package restrict the complete installation to Ruby 2.7? Or would conflict with other Ruby programs or development environments? (In Java, we install several JVM versions in parallel and each program can pick a fitting one).
Right, only single version of Ruby can be installed at time. While other ecosystems choose to support multiple versions it is not our case and it is on purpose. Maintaining several versions of Ruby is problematic (and I can't say that the modular versions get enough attention) and it would be even more problematic to maintain the whole ecosystem. We just finished mass rebuild and we needed to build 108 binary components, all these components would need to have their Ruby specific version in module.
BTW I think that Ruby itself might not be the limiting factor. Upstreams typically choose some official version just to reduce support matrix. For example Vagrant, the other prominent Ruby project in Fedora officially supports just Ruby 2.7, but it runs on Fedora just fine (although I have not tested it after the mass rebuild yet ;) ).
In Java there are a lot of dependency (and version) issues, too. This leads to quite elaborate spec files and version tracking, and a lot of work. So I'm used to it to some extent.
Redmine 4.2 needs rails 5.2, indeed. And in gemfile there are mostly very specific version specifications, likely as outdated as rails is. If I understand bundler correctly, I can store those gems in ~/vendor and make everything private to Redmine. Is that the proper way? Or what is the proper Fedora way?
Well, yes, probably. We don't have any precedent. But should it be me, I'd be thinking about using mix of vendored gems, such as Rails, but I'd try to stay with as much as possible system gems.
BTW I'd also start in Copr and I'd be fine to stay there. Because I'm not sure I'd want to undergo review of such package ...
Vít
ruby-sig@lists.fedoraproject.org