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.
Attachment:
signature.asc
Description: OpenPGP digital signature