Paul, Let me answer with a summary answer below: * Paul Wise <pabs@debian.org> [140512 09:13]: > I noted that ruby-term-ansicolor doesn't provide a gemspec file for > ruby2.0 (just 1.9.1 and 1.8) and doesn't declare this in its > dependencies. Simply rebuilding ruby-term-ansicolor with a current > chroot of unstable will fix this it seems since it only creates one > gemspec file in the 'all' directory. > > Is this something I should file a bug about or will it be handled during > the ruby2.0/ruby2.1 transitions? > > I think that the generated ruby dependencies for packages containing > version-specific gemspec files should reflect the available gemspec > files so that installing ruby-* packages pulls in the right ruby > versions for the package. This is correct analysis, but the behaviour is caused by an oversight in the old gem2deb. As you have noticed, newer gem2deb puts version-independent (=~ arch-independent) gemspecs into a shared directory. Version-dependent (=~ packages with C extensions) indeed need to depend on a specific ruby version, but they do that today. What's left to be done are sourceful uploads of arch:all packages like ruby-term-ansicolor; while this is a known todo it's going slowly. (Most) Packages that need reuploading/fixing can be found by inspecting the Ruby-Versions field, if it still says ruby1.8 or ruby1.9.1 then it's very likely affected. -- ,''`. Christian Hofstaedtler <zeha@debian.org> : :' : Debian Developer `. `' 7D1A CFFA D9E0 806C 9C4C D392 5C13 D6DB 9305 2E03 `-
Attachment:
pgp9Tx5z3H1Wh.pgp
Description: PGP signature