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
I can try building it in COPR, if you'd be interested in
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).
We can build it together with Rails (even with 6.1.x) in one repo, but
only in F35 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
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
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 :-)