On Mon, Jul 28, 2014 at 07:41:33PM +0200, Francesco Poli wrote: > On Sun, 27 Jul 2014 01:57:22 +0200 Christian Hofstaedtler wrote: > > > Re: ruby-debian no longer supporting ruby2.0, but apt-listbugs runs > > with 2.0 during a partial upgrade > > > > Given your description it would appear that all ruby packages would > > need to gain explicit rubyX.Y dependencies (similar to how this > > works for the Python packages). > > > > As an alternative, ruby-debian (and other known packages) may choose > > to Break older rubyX.Y versions. > > I would think that the second alternative is more practical than the > first: it should require changes in a significantly smaller set of > packages, shouldn't it? > > Moreover it looks conceptually more correct: after all, it's > ruby-debian and the other compiled Ruby libraries that no longer > support ruby2.0! > apt-listbugs and many other pure Ruby programs or libraries are > instead perfectly able to be interpreted by ruby2.0, as long as the > compiled Ruby libraries they depend on still support ruby2.0... > > Or am I completely off-track?
I think the correct way to fix this is to do like python does, i.e. binary extensions should gain a dependency on ruby (>= something). They should already depend on ruby | ruby-interpreter, so adding this versioned dependency on ruby will not be a big deal. I am working on a solution for this; I have added an entry for a minimum ruby dependency together with the existing data about interpreters to ruby-all-dev¹, committed a change that drops the dependency looo², and will modify gem2deb to inject that dependency. When all that is in the archive, we can just binNMU all binary extensions. ¹ http://deb.li/LD8y ² http://deb.li/Xi3h -- Antonio Terceiro <terce...@debian.org>
signature.asc
Description: Digital signature
