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 <[email protected]>: > 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 _______________________________________________ ruby-sig mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
