OoO En cette fin de matinée radieuse du dimanche 06 mars 2011, vers
11:40, Lucas Nussbaum <lucas@lucas-nussbaum.net> disait :
> Note that, for applications written in Ruby and packaged in Debian, we
> will make sure that they work no matter what /usr/bin/ruby points to (if
> necessary, by forcing the shebang to ruby1.8, and installing the correct
> dependencies). What might break is software manually installed by users.
> I don't see how that situation is different from the Java one.
This is also what is done with Python. We get very little complaints
with this. However, maybe the Python roadmap is easier to understand and
less applications get broken when upgrading to a new major version.
Breaking applications that are installed outside of the package manager
is bad but it is far less worse than breaking applications installed
with the package manager.
>> > Anyway. We are early in the wheezy release cycle. If switching ruby
>> > implementations using alternatives turns out to be a bad idea, we can
>> > switch back to the former approach at some point. And we will arguments
>> > to reply to users who currently want it.
>>
>> Do you really need to break hundreds of user systems just to make a
>> handful of whiners happy?
> I am under the impression that it's not "a handful of whiners", but that
> the consensus in the Ruby community is that we should switch to
> alternatives.
Do they really understand that alternatives may break a lot of things on
user systems? By reading your blog, I understand that the Ruby community
(or a part of it) does not really understand that Debian does want to
provide a robust way to manage applications. If the user install
software X written in Ruby with apt, then uses "update-alternatives" to
switch Ruby version and then software X is broken, it seems we are to
blame because using update-alternatives should not break installed
softwares.
--
Program defensively.
- The Elements of Programming Style (Kernighan & Plauger)
Attachment:
pgp56SuTOpdKX.pgp
Description: PGP signature