On Fri, 16 Nov 2018, 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. > > I think spending more hours to rebuild is better than backporting > security patches to older versions. > > > 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. And I think you already have too many packages. Alex >
Attachment:
signature.asc
Description: PGP signature