Re: Bug#548917: Please use alternatives system to manage the ruby symlink

[akira yamada]

Hi,

> The existing ruby package simply sticks a symlink into /usr/bin/ruby
> to point to ruby1.8. I was surprised to find that this was not
> using the alternatives system, so that you can manage this yourself.

I have a rough idea about ruby* packages.

ruby package:
  now:
    provides /usr/bin/ruby file
    depends on ruby1.8 package
  new:
    does not provides /usr/bin/ruby* file
    depends on latest version of ruby* packages
      (for current testing: Depends: ruby1.9.1 | ruby1.8 | jruby1.1 | ...
       for after squeeze?:  Depends: ruby1.9.2 | jruby1.2 | ...)
    (description points out latest version of ruby* packges)

ruby1.8 package:
  now:
    provides /usr/bin/ruby1.8 file
    no alternatives
  new:
    provides /usr/bin/ruby1.8 file (no change)
    alternatives for /usr/bin/ruby

ruby1.9 package:
  now:
    provides /usr/bin/ruby1.9 file
    no alternatives
  new:
    provides /usr/bin/ruby1.9.0 file
    alternatives for /usr/bin/ruby/1.9 and /usr/bin/ruby

ruby1.9.1 package:
  now:
    provides /usr/bin/ruby1.9.1 file
    no alternatives
  new:
    provides /usr/bin/ruby1.9.1 file (no change)
    alternatives for /usr/bin/ruby1.9 and /usr/bin/ruby

I think that packages using Ruby language
should not use /usr/bin/ruby in the above package design.
(Users can use them freely of course.)


Note: there are some software that
don't depend on specified version/variant of Ruby.
So it may be better to provide symlinks
such as /usr/bin/ruby-compat-<compat-level>
for compatibility.
(Here comapt-level is "1.9.1" for Ruby 1.9.1 and 1.9.2.)


Note2:
I know that lucas have a new policy plan.
And I think that we should have more time to discuss about it.
During that time we should have small and minor update about current policy.
I think the above idea is part of such minor updates.

--
ay


--
To UNSUBSCRIBE, email to debian-ruby-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Lucas Nussbaum]

On 04/10/09 at 10:27 +0900, akira yamada / ?????? wrote:

> Hi,
>
> > The existing ruby package simply sticks a symlink into /usr/bin/ruby
> > to point to ruby1.8. I was surprised to find that this was not
> > using the alternatives system, so that you can manage this yourself.
>
> I have a rough idea about ruby* packages.
>
> ruby package:
>   now:
>     provides /usr/bin/ruby file
>     depends on ruby1.8 package
>   new:
>     does not provides /usr/bin/ruby* file
>     depends on latest version of ruby* packages
>       (for current testing: Depends: ruby1.9.1 | ruby1.8 | jruby1.1 | ...
>        for after squeeze?:  Depends: ruby1.9.2 | jruby1.2 | ...)
>     (description points out latest version of ruby* packges)
>
> ruby1.8 package:
>   now:
>     provides /usr/bin/ruby1.8 file
>     no alternatives
>   new:
>     provides /usr/bin/ruby1.8 file (no change)
>     alternatives for /usr/bin/ruby
>
> ruby1.9 package:
>   now:
>     provides /usr/bin/ruby1.9 file
>     no alternatives
>   new:
>     provides /usr/bin/ruby1.9.0 file
>     alternatives for /usr/bin/ruby/1.9 and /usr/bin/ruby
>
> ruby1.9.1 package:
>   now:
>     provides /usr/bin/ruby1.9.1 file
>     no alternatives
>   new:
>     provides /usr/bin/ruby1.9.1 file (no change)
>     alternatives for /usr/bin/ruby1.9 and /usr/bin/ruby
>
> I think that packages using Ruby language
> should not use /usr/bin/ruby in the above package design.
> (Users can use them freely of course.)
>
>
> Note: there are some software that
> don't depend on specified version/variant of Ruby.
> So it may be better to provide symlinks
> such as /usr/bin/ruby-compat-<compat-level>
> for compatibility.
> (Here comapt-level is "1.9.1" for Ruby 1.9.1 and 1.9.2.)
>
>
> Note2:
> I know that lucas have a new policy plan.
> And I think that we should have more time to discuss about it.
> During that time we should have small and minor update about current policy.
> I think the above idea is part of such minor updates.

Hi,

I agree with the plan to use alternatives. However, I fear that
switching to alternatives will break many ruby applications (packaged in
Debian) that use /usr/bin/ruby instead of /usr/bin/ruby1.8. So that
change isn't that minor, since we need to advertise that using
/usr/bin/ruby is not allowed unless your application is really
compatible with all ruby versions (that means that you need to depend on
libfoo-ruby1.8 and libfoo-ruby1.9, currently, too).

I think that the first step is really to provide a way for libraries to
support several ruby versions at the same time (so we can remove those
1.8, 1.9, 1.9.1 suffixes). That means something like ruby-support
(though I agree that we could discuss it more ; also, I don't have time
to work on it currently). Once this is done, it will be easier for
applications to support several ruby versions at the same time, so the
switch to alternatives will also be easier.

I'll try to talk to some people to see if they could work on
ruby-support themselves. Also, I've talked with a release team member,
and the plans for squeeze seems to be to freeze in february. We have to
decide whether we want to push things a lot, and do it before squeeze,
or postpone them and do them for squeeze+1.
--
| Lucas Nussbaum
| lucas@...   http://www.lucas-nussbaum.net/ |
| jabber: lucas@...             GPG: 1024D/023B3F4F |


--
To UNSUBSCRIBE, email to debian-ruby-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...