On Thu, Aug 29, 2024 at 11:21:51PM +0200, Cédric Boutillier wrote: > Hi, > > I have been looking at the gem dependency failure with nanoc > https://people.debian.org/~boutil/ruby3.3/mass-rebuild/builds/10/nanoc/nanoc_4.13.0-1+rebuild1724942411_amd64-2024-08-29T14:40:12Z.build > > nanoc-core.gemspec asks base64 ~> 0.2 > > ruby3.1 ships base64 v 0.1.1 > ruby3.3 ships base64 v 0.2.0 > we have also ruby-base64 0.2.0 > > Since libruby3.3 provides ruby-base64 0.2.0, as soon as we install it, > the versioned dependency on ruby-base64 will be satisfied. However, the > corresponding files will be available only for ruby3.3, and not for > ruby3.1. > > This causes thus the Rubygems dependency resolution to fail with > ruby3.1. This is a problem only in the transition period when ruby-dev > will depend on both ruby3.1-dev and ruby3.3-dev. I can for now > deactivate the dependency check in debian/rules, but I was wondering if > you had ideas to fix this problem more globally.
This is tricky, and we have gone back and forth on it: some times we went in favor of the versions provided by ruby, and in some other cases we went ahead with the standalone packages. For some time we relied on rubygems from Ruby. In the last few years we packaged rubygems as a standalone package. We have removed standalone packages in favor of the ones provided by Ruby when Ruby started providing them. I think the only solution that avoids this corner case during transitions is to stop providing packages from libruby*, at least in the cases where we already have the corresponding standalone packages.
signature.asc
Description: PGP signature
