On Tue, Jun 30, 2020 at 06:06:56PM +0530, Pirate Praveen wrote: > > > On Tue, Jun 30, 2020 at 09:26, Antonio Terceiro <terceiro@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. People regularly install stuff from backports regardless of specifically needing it. Any users that get such new ruby from backports, either because of gitlab, or just because they can, will be susceptible to having other Ruby software from stable randomly break. An example: IIRC both chef and puppet needed fixes for ruby2.7; this means that gitlab users with this new ruby will be unable to manage their servers with either chef or puppet, unless you also fix those in stable and/or provide backports. > > 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). To be clear: my opinion is that such backport should not be uploaded to Debian Backports, at all. I don't really care if you include it in fasttrack.
Attachment:
signature.asc
Description: PGP signature