On 11/17/18 12:57 AM, Antonio Terceiro wrote: > Yes, but if you install the ruby >= 2.4 that is needed for gitlab, you > also want other stuff written in ruby to keep working, so you would also > need to rebuild *all* extensions. but this is not viable as I try to > ellaborate below. Only the 43 required for gitlab I assume, as other packages will continue to use ruby 2.3 if we make ruby 2.5 available as /usr/bin/ruby2.5 only. Did I make a mistake here in the estimation? >> I think spending more hours to rebuild is better than backporting >> security patches to older versions. > > By this argument we would not have stable releases. But we are talking about backports whose aim to get newer packages for stable releases. > Anyway, when you say older versions, you mean older versions of what? > ruby has security support in stable, and does the majority of toolchain > packages in stable. Backporting security fixes to older versions of gitlab. > And, when making a stable update, you not only want to fix the security > issue, you also want to not break existing stuff that works. A targeted > security fix is way easier to verify as not breaking stuff as an entire > new upstream release with new features, new bugs (by definition), and > new small incompatibilities. But we are talking about backports here which is explicitly meant for newer upstream versions. > There is a reason you usually don't see backports of programming > languages, and other toolchain-related packages: a backport is, by > definition, a build of newer software against an older base. The moment > you start introducing changes to that base itself, what includes > toolchain packages such as interpreters, and other base packages, you > open yourself up to a ton of integration problems, because the entire > system was not tested against that base. I can see at least golang-go has backports and a large number of golang packages in stretch-backports. > If upstream cares about having newer gitlab on Debian stable from Debian > backports, they will need to care about it actually working with ruby > from stable. This could mean just keeping ruby 2.3 in their CI matrix so > you know it still works, and avoid using features that are not present > in ruby 2.3. I have requested them to support ruby 2.3 and waiting for their response. You can see the situation with gitlab 11.1.8 (the first gitlab version that dropped ruby 2.3 support) https://gitlab.com/pravi/gitlab-ce/pipelines/36935971 Possibly the failures are in tests only but someone needs to fix them. > I really appreciate your efforts. I know maintaining gitlab is no small > feat, and is a lot of work. I don't manage a gitlab installation myself > but there are people out there who do, and I'm sure they would join me > in thanking you. But requiring a newer toolchain is going too far away > from what the backports repository is intended for. > Thanks for your kind words and suggestions. I'm looking at all the options and hopefully we can find a way that is agreeable to all parties (at the least by unofficial repo).
Attachment:
signature.asc
Description: OpenPGP digital signature