[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#747858: libruby2.1: circular dependency hell



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 <terceiro@debian.org>

Attachment: signature.asc
Description: Digital signature


Reply to: