Hi,

* Axel Beckert <a...@debian.org> [140331 01:36]:
> Hi,
> 
> >    * ruby: remove Breaks/Conflicts/Replaces against old interpreter packages
> >      as this will force the removal of old interpreters from users' systems
> >      (Closes: #740733)
> >      .
> >      The following upgrade scenarios from wheezy were tested, still work 
> > fine,
> >      and leave the old interpreters alone:
> >      - ruby
> >      - ruby + ruby1.8
> >      - ruby + apt-listbugs
> >      - ruby + ruby1.8 + apt-listbugs
> >      - ruby1.8 + apt-listbugs
> 
> I've just run into a scenario not listed above in which left me
> without /usr/bin/ruby afterwards. This scenario is likely not
> happening during an dist-upgrade from Wheezy to Jessie as it's planned
> now, but may still hit other people who are running unstable.
> 
> After I've read this changelog entry, I installed glark (which is
> currently ruby1.8 only) again to notice when there's an updated
> version working with a newer release of Ruby.
[..]
> I noticed that /usr/bin/ruby points back to ruby1.8:
> update-alternatives: using /usr/bin/ruby1.8 to provide /usr/bin/ruby (ruby) 
> in auto mode
> 
> I'm not sure if this is a bug in update-alternatives as it seems to
> happily overwrite a file which was installed by a package -- I would
> expect that it should prevent that.

One could argue that this is a bug in u-a, but u-a itself does not
violate policy; certainly (now that ruby1.9.1, 2.0 have stopped
being part of the scheme), ruby1.8 violates policy.

> At least I think, it's worthwile to consider Marga's idea of uploading
> ruby1.8 once more to remove that call to update-alternatives to
> prevent this kind of issue.

This really only helps users of unstable, and likely is quite some
work (IIRC 1.8 now FTBFS).

> Another option I can imagine is to keep the update-alternatives
> mechanism for one more release but with just one alternative.
> 
> ... or make update-alternatives not to overwrite package-installed
> files. That's dpkg-divert's job.

Keeping update-alternatives breaks when a user has previously
manually chosen ruby1.8.

I don't see a way out of this other than
  1) cyclic dependencies
  2) uploading an empty ruby1.8 package.

Both of these options prevent users from keeping a working 1.8
interpreter, but because of update-alternatives in 1.8 this goal
directly conflicts with any way of making any new version the new
blessed default.

> I'm neither sure where to actually file a bug report for that issue
> nor which severity it should have (I can imagine everything, from
> minor to grave -- as it deletes a file installed by another package).
> Any advice or comment is appreciated.

Cloning this bug with severity minor saying 'please allow keeping
ruby1.8 installed [for stable users]' is probably welcome, but at
this point I do not see how it's possible to do this.

Thanks for the feedback,
-- 
 ,''`.  Christian Hofstaedtler <z...@debian.org>
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-

Attachment: signature.asc
Description: Digital signature

Reply via email to