On Mon, 20 Jan 2014 14:28:43 -0300 Antonio Terceiro wrote: > On Sun, Jan 19, 2014 at 05:33:58PM +0100, Francesco Poli wrote: > > On Sun, 19 Jan 2014 10:33:43 +0100 Antonio Terceiro wrote: > > > > > On Fri, Jan 17, 2014 at 11:18:46PM +0100, Francesco Poli wrote: > > [...] > > > > Could you please describe the chosen strategy? > > [...] > > > > > > we will make the following change: > > > > > > - librubyX.Y.Z depends on rubyX.Y.Z > > > - rubyX.Y.Z depends on ruby > > > - ruby depends on the default ruby > > > - ruby conflicts with all obsolete interpreters > > > > > > so this will force ruby1.8 to be removed on upgrades. > > > > Thanks for your reply, Antonio. > > > > So this will force everyone using any version of Ruby to also have the > > default version, no matter what... > > one bit I forgot: we also decided that we won't support more than one > version in stable releases, so the 'default' version is actually the > unique one.
I am not too happy to hear that: as far as I know, Debian gives more choice to users for other languages (such as Python, AWK, all GCC languages, ...). I hope this situation will improve in the future. I think that supporting at least a couple of major versions (a more mature one, used as default interpreter, and a more recent bleeding edge one) would be great. > > The infrastructure for having multiple versions simulaneously will stay > only to support clean transitions in testing/sid. I hope this infrastructure will be put to good use for stable releases too... > > > Would the following simpler strategy work as well? > > > > - any supported librubyX.Y.Z conflicts with all obsolete librubyA.B.C > > > > This should ensure that libruby1.8 (and thus ruby1.8) gets removed on > > upgrades, without forcing everyone to have the "ruby" package installed. > > > > Do you agree? > > Or does the simpler strategy have any drawback? > > It does not work if you don't have packages containing C extensions (and > therefore depending on librubyX.Y.Z) Why not? Pure Ruby libraries depend on "ruby | ruby-interpreter". Hence, as soon as an obsolete rubyA.B.C stops providing ruby-interpreter (and eventually gets entirely removed from Debian), systems with pure Ruby libraries installed will pull in "ruby", which will depend the default rubyD.S.I, which, in its turn, will depend on librubyD.S.I conflicting with all obsolete librubyA.B.C ... I am under the impression that this should ensure that rubyA.B.C and librubyA.B.C get removed on upgrades. But I may well be wrong: please correct me. Thanks for your time and patience! -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! ..................................................... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
pgpOpOizAHH9t.pgp
Description: PGP signature
