On Tue, Jun 30, 2020 at 09:26, Antonio Terceiro <terce...@debian.org>
wrote:
On Tue, Jun 30, 2020 at 05:21:53PM +0530, Pirate Praveen wrote:
Hi,
gitlab stopped working with ruby 2.5 (they officially dropped
support long
ago, but it was working fine till now). See
https://gitlab.com/gitlab-org/gitlab/-/issues/225251 for details.
In last
stable release we were lucky things worked with ruby 2.3 even
though it was
not officially supported.
Option 1. Backport ruby 2.7
I could upload it to fasttrack as well, but I'd prefer more people
benefit
it by having it in backports since I'm doing the backport work
anyway.
On a gitlab installation,
$ ls /usr/share/rubygems-integration/2.5.0/specifications/ -1 |wc -l
47
So we will have to backport at least these many modules as well.
Option 2. Patch gitlab to work with ruby 2.5
We can also try to fix issues with ruby 2.5 as and when we notice
it as
well, but if there not many takers for it, I don't think that can
work well.
Option 1 requires only packaging knowledge but Option 2 requires
ruby
knowledge.
For such a backport to work for gitlab, you would need to either a)
backport ruby-defaults as well to make /usr/bin/ruby by ruby2.7 or b)
change all binaries in gitlab to use /usr/bin/ruby2.7 explicitly.
a) is very risky as none of the other Ruby software in stable has been
tested with ruby2.7. This will cause random stuff to break and I don't
want to be involved in supporting that.
Thanks for your input. Though only someone explicitly installing ruby
from backports will get ruby 2.7 so it is not correct to say it is
going to regular stable. And all gitlab dependencies are already tested
with ruby 2.7 in unstable.
b) requires changing gitlab somehow anyway, so you might as well fix
the
actual issues with ruby2.5 instead. FWIW I don't think it's realistic
to
maintain a fast-moving, enormous beast such as gitlab for stable and
expect to not need to get your hands dirty in its code.
Like I said, it is about what expertise you need. For backporting, I
can use the expertise I already have in backporting and depend on
upstream for ruby specific help if I stay close to what they officially
support (if the issue is reproducible in their ci). I'd have to get
into ruby code often, but if some of it can be avoided, by even having
to do some extra work, I'd prefer to.
Anyway this specific issue is resolved and I will consider this again
if/when we get such issues in future. Thanks for the patch.
I'd still like to know if anyone else in the team would be interested
in maintaining such a backport. If no one volunteers, I can still have
it in fasttrack, which will affect only gitlab users (for now, no other
software in there yet).
