On Fri, Nov 16, 2018 at 10:17:06PM +0530, Pirate Praveen wrote: > On 11/16/18 9:44 PM, Antonio Terceiro wrote: > > On Fri, Nov 16, 2018 at 07:56:16PM +0530, Pirate Praveen wrote: > > [...] > >> Since gitlab 10.11.8 requires ruby >= 2.4, I will need to backport > >> ruby first > > > > I would advice against doing that. You would also need to > > rebuild/backport every single package that contains a Ruby extension > > written in C so that it has a .so library built against that new Ruby > > interpreter. And there is also the possibility that this new ruby will > > break unrelated software in stretch. > > But packages that specifically declare ruby >= 2.3 will only pickup this > ruby version from backports, right? I counted 43 gems required for > gitlab that needs a rebuild. (assuming you mean s/2.3/2.4/) 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. > 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. 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. 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. > > What exactly does "requires ruby >= 2.4" mean? Are there actual features > > in gitlab that need ruby >= 2.4? If there is a technical reason why > > this new gitlab can't run with the ruby from stretch, I would recommend > > not backporting it at all (or at least not in the official backports > > repository, anyway). > > This particular version might work with ruby 2.3 as well. But newer > versions are tested with ruby 2.4 only and upstream only supports ruby > 2.4 version. We don't run all the tests to really check if it works with > ruby 2.3. The idea of backporting newer gitlab versions is to stay close > to upstream supported releases. 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. 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 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.
Attachment:
signature.asc
Description: PGP signature