Ruby plans for squeeze

[Lucas Nussbaum]

[ M-F-T set to debian-ruby@ ]

Hi,

We (Ruby interpreter maintainers) would like to hear the opinion of
other people interested in Ruby on our proposed plans for Ruby in
squeeze.

After discussion will have happened on debian-ruby@, we will also ask
the release team.

Current status
==============
In lenny, we will ship two versions of the Ruby interpreter:

Ruby 1.8 (the "stable" version) (package: ruby1.8 1.8.7.72-3)

Ruby 1.9.0 (the "new stable" version) (package: ruby1.9 1.9.0.2-8)

Both ruby1.8 and ruby1.9 source packages build several binary packages:
- ruby1.n (with n=8,9) (arch: any, contains the interpreter binary
  and other things, very small)
- libruby1.n (arch: any, contains /usr/lib/libruby1.n.so.1.n and
  most of the stdlib)
- ruby1.n-dev (arch: any, provides headers, etc)
- irb1.n, ri1.n, rdoc1.n (arch: all, provide developement tools)
- some shared libs, such as libdbm-ruby1.n, libgdbm-ruby1.n,
  libopenssl-ruby1.n, etc. (arch: any, split out libruby1.n to
  remove some dependencies)

Packages currently depend either on ruby1.n or libruby1.n when they
need ruby 1.n.

Ruby 1.8 plans
==============
It is not clear yet whether we will ship a ruby1.8 version in squeeze.
It will depend on how fast Ruby 1.9 is adopted. It is highly
possible that we decide to remove Ruby 1.8 from squeeze quite late in the
release process, to avoid supporting it in a stable release.

In all cases, we don't plan to change the way ruby 1.8 is packaged.

Ruby 1.9 plans
==============
Ruby 1.9 is a different story. Upstream decided to version the API,
and add a third digit to the library search path:
/usr/lib/ruby/1.9.1 instead of /usr/lib/ruby/1.9
Because of this, migrating from 1.9.0 (in lenny) to 1.9.1 (will be
released upstream soon) won't be simple.

We have two solutions:
(A) allow for several ruby 1.9.{x,y} versions to be in the archive and
installed at the same time, and do not support upgrades between them.
(B) allow only one ruby1.9.{x,y} version to be in a given suite,
provide upgrades between 1.9.{x,y}, and do mass-transitions of all
ruby libs when a new 1.9.z is released. (ruby would have to migrate
together with all its reverse-deps)

We would prefer to do (B) since API changes are likely to be minor,
and new 1.9.z releases are likely not to be too frequent (upstream
said ~ once a year ; next is due Dec 09 or Jan 10).

Proposed solution:

1) drop the libruby1.9 package. Replace it with libruby1.9.1.
   ruby1.9 stays, but depends on libruby1.9.1. Here, "1.9.1" indicates
   the Ruby API version (or soname), not the version of Ruby. If Ruby
   1.9.2 stays API-compatible with 1.9.1, this will not be changed
   (according to the upstream developers).

2) packages using ruby have to depend on libruby1.9.1. If they also
   require the interpreter, they need to also depend on libruby1.9.1,
   to indicate that they depend on this specific version of the API.
   Depending on ruby1.9 without depending on libruby1.9.1 is an RC bug.

3) ask library maintainers to install to
   /usr/lib/ruby/vendor_ruby/1.9.1/ instead of /usr/lib/ruby/1.9.1/,
   to get out of the mix between standard libs and third-party libs.

Migration plans:
================
1.9.0->1.9.1 migration:
all packages have to be updated to depend on ruby1.9 and libruby1.9.1,
and install their files in /usr/lib/ruby/vendor_ruby/1.9.1/

1.9.1->1.9.2 migration, and later:
all packages need to be updated to depend on ruby1.9 and libruby1.9.2,
and install their files in /usr/lib/ruby/vendor_ruby/1.9.2/

Open Questions:
===============
1) Should we allow for several ruby1.9.n versions in the same suite
at a given time?

2) Library packages naming: change from libxxx-ruby1.9 to something
else? (would be nice to use that opportunity)
ruby-xxx? (simpler)
ruby1.9-xxx? stay with libxxx-ruby1.9?
libxxx-ruby1.9.1 or ruby1.9.1-xxx? (required if we want to support
several versions at the same time in the archive)


So, comments? :-)
--
| 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@...

[Richard Hurt-2]

Lucas Nussbaum wrote:
> Hi,
>
> ...snip...
>
> So, comments? :-)
>    

I'm pretty new to the world of Ruby and Debian packages so the above is
hard for me to parse but it did spur a couple of questions in my brain.  
How do the proposed solutions affect the packaging of Rails, GEMS,
Plugins, etc?  Could we make it easier to maintain these external Ruby
dependencies?

Thanx!

--------------------------
Richard Hurt
KangarooBox, LLC.
  e: rnhurt@...
  p: 502-298-5422 Direct
  w: http://KangarooBox.com
--------------------------


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

[Luiz Vitor Martinez Cardoso]

Ruby 1.9 isn't intended to production. It's a transitional release that aims to stabilize the code base to 2.0 release.

Probably it can't be on debian stable version!


Regards,
Luiz Vitor.

On Tue, Feb 3, 2009 at 12:24 PM, Lucas Nussbaum <lucas@...> wrote:

[ M-F-T set to debian-ruby@ ]

Hi,

We (Ruby interpreter maintainers) would like to hear the opinion of
other people interested in Ruby on our proposed plans for Ruby in
squeeze.

After discussion will have happened on debian-ruby@, we will also ask
the release team.

Current status
==============
In lenny, we will ship two versions of the Ruby interpreter:

Ruby 1.8 (the "stable" version) (package: ruby1.8 1.8.7.72-3)

Ruby 1.9.0 (the "new stable" version) (package: ruby1.9 1.9.0.2-8)

Both ruby1.8 and ruby1.9 source packages build several binary packages:
- ruby1.n (with n=8,9) (arch: any, contains the interpreter binary
 and other things, very small)
- libruby1.n (arch: any, contains /usr/lib/libruby1.n.so.1.n and
 most of the stdlib)
- ruby1.n-dev (arch: any, provides headers, etc)
- irb1.n, ri1.n, rdoc1.n (arch: all, provide developement tools)
- some shared libs, such as libdbm-ruby1.n, libgdbm-ruby1.n,
 libopenssl-ruby1.n, etc. (arch: any, split out libruby1.n to
 remove some dependencies)

Packages currently depend either on ruby1.n or libruby1.n when they
need ruby 1.n.

Ruby 1.8 plans
==============
It is not clear yet whether we will ship a ruby1.8 version in squeeze.
It will depend on how fast Ruby 1.9 is adopted. It is highly
possible that we decide to remove Ruby 1.8 from squeeze quite late in the
release process, to avoid supporting it in a stable release.

In all cases, we don't plan to change the way ruby 1.8 is packaged.

Ruby 1.9 plans
==============
Ruby 1.9 is a different story. Upstream decided to version the API,
and add a third digit to the library search path:
/usr/lib/ruby/1.9.1 instead of /usr/lib/ruby/1.9
Because of this, migrating from 1.9.0 (in lenny) to 1.9.1 (will be
released upstream soon) won't be simple.

We have two solutions:
(A) allow for several ruby 1.9.{x,y} versions to be in the archive and
installed at the same time, and do not support upgrades between them.
(B) allow only one ruby1.9.{x,y} version to be in a given suite,
provide upgrades between 1.9.{x,y}, and do mass-transitions of all
ruby libs when a new 1.9.z is released. (ruby would have to migrate
together with all its reverse-deps)

We would prefer to do (B) since API changes are likely to be minor,
and new 1.9.z releases are likely not to be too frequent (upstream
said ~ once a year ; next is due Dec 09 or Jan 10).

Proposed solution:

1) drop the libruby1.9 package. Replace it with libruby1.9.1.
  ruby1.9 stays, but depends on libruby1.9.1. Here, "1.9.1" indicates
  the Ruby API version (or soname), not the version of Ruby. If Ruby
  1.9.2 stays API-compatible with 1.9.1, this will not be changed
  (according to the upstream developers).

2) packages using ruby have to depend on libruby1.9.1. If they also
  require the interpreter, they need to also depend on libruby1.9.1,
  to indicate that they depend on this specific version of the API.
  Depending on ruby1.9 without depending on libruby1.9.1 is an RC bug.

3) ask library maintainers to install to
  /usr/lib/ruby/vendor_ruby/1.9.1/ instead of /usr/lib/ruby/1.9.1/,
  to get out of the mix between standard libs and third-party libs.

Migration plans:
================
1.9.0->1.9.1 migration:
all packages have to be updated to depend on ruby1.9 and libruby1.9.1,
and install their files in /usr/lib/ruby/vendor_ruby/1.9.1/

1.9.1->1.9.2 migration, and later:
all packages need to be updated to depend on ruby1.9 and libruby1.9.2,
and install their files in /usr/lib/ruby/vendor_ruby/1.9.2/

Open Questions:
===============
1) Should we allow for several ruby1.9.n versions in the same suite
at a given time?

2) Library packages naming: change from libxxx-ruby1.9 to something
else? (would be nice to use that opportunity)
ruby-xxx? (simpler)
ruby1.9-xxx? stay with libxxx-ruby1.9?
libxxx-ruby1.9.1 or ruby1.9.1-xxx? (required if we want to support
several versions at the same time in the archive)


So, comments? :-)
--
| 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@...

--
Regards,

Luiz Vitor Martinez Cardoso
cel.: (11) 8187-8662
blog: rubz.org
engineer student at maua.br

"Posso nunca chegar a ser o melhor engenheiro do mundo, mas tenha certeza de que eu vou lutar com todas as minhas forças para ser o melhor engenheiro que eu puder ser"

[Lucas Nussbaum]

On 03/02/09 at 09:45 -0500, Richard Hurt wrote:

> Lucas Nussbaum wrote:
>> Hi,
>>
>> ...snip...
>>
>> So, comments? :-)
>
> I'm pretty new to the world of Ruby and Debian packages so the above is  
> hard for me to parse but it did spur a couple of questions in my brain.  
> How do the proposed solutions affect the packaging of Rails, GEMS,  
> Plugins, etc?  Could we make it easier to maintain these external Ruby  
> dependencies?

It doesn't affect it.

In Debian, we don't use the rubygems code that is shipped together with
ruby 1.9.{0,1}. Instead, we directly package the rubygems code shipped
by upstream rubygems developers.

I'm not sure if there are things to change with the way we currently
address gems. However, it sounds like most of it is a totally different
issue than the ones discussed here, no?
--
| 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@...

[Lucas Nussbaum]

On 03/02/09 at 12:52 -0200, Luiz Vitor Martinez Cardoso wrote:
> Ruby 1.9 isn't intended to production. It's a transitional release that aims
> to stabilize the code base to 2.0 release.
>
> Probably it can't be on debian stable version!

Quoting http://www.ruby-lang.org/:
| Ruby 1.9.1 is released. This is the first stable release of the Ruby
| 1.9 series.
|
| Ruby 1.9 is a new series of Ruby. It is modern, faster, with clearer
| syntax, multilingualized, a much improved version of Ruby.
|
| Ruby 1.8 series has been used since 2003 and many great products were
| born on it.
|
| Today, the Ruby 1.9 series starts its history as the 1.8 series did.
|
| Please note that Ruby 1.8 still remains. 1.8.8 will be released this
| year.

Looking at how Ruby developers usually adopt things, it is very likely
that, by the time squeeze is released (in 18 to 24 months), Ruby 1.9
will be the most popular ruby version.
--
| 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@...

[Antonio Terceiro]

Lucas Nussbaum escreveu isso aí:
> Ruby 1.8 plans
> ==============
> It is not clear yet whether we will ship a ruby1.8 version in squeeze.
> It will depend on how fast Ruby 1.9 is adopted. It is highly
> possible that we decide to remove Ruby 1.8 from squeeze quite late in the
> release process, to avoid supporting it in a stable release.
>
> In all cases, we don't plan to change the way ruby 1.8 is packaged.

I think that the Python packagers could contribute a lot to the discussion of
this point. python2.5 is not even the latest upstream stable release anymore
and there are still a couple of packages that depend on 2.4:

terceiro@morere~> apt-cache rdepends python2.4 | wc -l
73
terceiro@morere~> apt-cache rdepends python2.5 | wc -l
237

It's possible that removing Ruby 1.8 from squeeze also removes some important
applications that depend on it, so we need to compare the damage of losing such
packages to the effort of keeping Ruby 1.8 on the stable release.

> Ruby 1.9 plans
> ==============
> Ruby 1.9 is a different story. Upstream decided to version the API,
> and add a third digit to the library search path:
> /usr/lib/ruby/1.9.1 instead of /usr/lib/ruby/1.9
> Because of this, migrating from 1.9.0 (in lenny) to 1.9.1 (will be
> released upstream soon) won't be simple.
>
> We have two solutions:
> (A) allow for several ruby 1.9.{x,y} versions to be in the archive and
> installed at the same time, and do not support upgrades between them.
> (B) allow only one ruby1.9.{x,y} version to be in a given suite,
> provide upgrades between 1.9.{x,y}, and do mass-transitions of all
> ruby libs when a new 1.9.z is released. (ruby would have to migrate
> together with all its reverse-deps)
>
> We would prefer to do (B) since API changes are likely to be minor,
> and new 1.9.z releases are likely not to be too frequent (upstream
> said ~ once a year ; next is due Dec 09 or Jan 10).
>
> Proposed solution:
>
> 1) drop the libruby1.9 package. Replace it with libruby1.9.1.
>    ruby1.9 stays, but depends on libruby1.9.1. Here, "1.9.1" indicates
>    the Ruby API version (or soname), not the version of Ruby. If Ruby
>    1.9.2 stays API-compatible with 1.9.1, this will not be changed
>    (according to the upstream developers).
>
> 2) packages using ruby have to depend on libruby1.9.1. If they also
>    require the interpreter, they need to also depend on libruby1.9.1,
>    to indicate that they depend on this specific version of the API.
>    Depending on ruby1.9 without depending on libruby1.9.1 is an RC bug.
>
> 3) ask library maintainers to install to
>    /usr/lib/ruby/vendor_ruby/1.9.1/ instead of /usr/lib/ruby/1.9.1/,
>    to get out of the mix between standard libs and third-party libs.

This is nice.
 

> Migration plans:
> ================
> 1.9.0->1.9.1 migration:
> all packages have to be updated to depend on ruby1.9 and libruby1.9.1,
> and install their files in /usr/lib/ruby/vendor_ruby/1.9.1/
>
> 1.9.1->1.9.2 migration, and later:
> all packages need to be updated to depend on ruby1.9 and libruby1.9.2,
> and install their files in /usr/lib/ruby/vendor_ruby/1.9.2/
>
> Open Questions:
> ===============
> 1) Should we allow for several ruby1.9.n versions in the same suite
> at a given time?
>
> 2) Library packages naming: change from libxxx-ruby1.9 to something
> else? (would be nice to use that opportunity)
> ruby-xxx? (simpler)
> ruby1.9-xxx? stay with libxxx-ruby1.9?

Having ruby-xxx is sexier, but will depend on whether Ruby 1.8 will stay or not
to avoid ambiguity. If it stays, I'd say to use ruby1.n-xxx or even to stay
with current naming scheme.

> libxxx-ruby1.9.1 or ruby1.9.1-xxx? (required if we want to support
> several versions at the same time in the archive)

Thanks for your effort on pushing this discussion.

There were my 2 cents,

--
Antonio Terceiro <terceiro@...>
http://people.softwarelivre.org/~terceiro/
GnuPG ID: 0F9CB28F

[Adeodato Simó-4]

Hello, Lucas, I hope you don't mind me popping in. My presence on this
list seems to go back to my Rubyist days, heh. So, here are my comments
on the matter, in hopes it can help you guys come up with an approach
that satisfies everybody. (PS: Meh, I ended up writing more than I
would've liked, sorry about that.)

> Ruby 1.9 is a different story. Upstream decided to version the API,
> and add a third digit to the library search path:
> /usr/lib/ruby/1.9.1 instead of /usr/lib/ruby/1.9
> Because of this, migrating from 1.9.0 (in lenny) to 1.9.1 (will be
> released upstream soon) won't be simple.

Let's talk this first. The first question is: what is compatible, and
what is not, between 1.9.x and 1.9.<x+1>. I'll assume, and you'll tell me
if I'm wrong, that Ruby code that runs fine with eg. 1.9.0, will run
fine with 1.9.1, with few or none exceptions that will not be possible
to know in advance. It is very important that we get this information
right (but I can't imagine it could be any other way).

Binary extensions, OTOH, will most likely need to be rebuilt across
1.9.x releases (it'd be awesome if this was not the case, but I don't
think that's gonna happen). I'll assume, too, that most extensions would
rebuild just fine without source changes, but that some will need
adjustements for those "minor API changes" you mention.

> We have two solutions:
> (A) allow for several ruby 1.9.{x,y} versions to be in the archive and
> installed at the same time, and do not support upgrades between them.
> (B) allow only one ruby1.9.{x,y} version to be in a given suite,
> provide upgrades between 1.9.{x,y}, and do mass-transitions of all
> ruby libs when a new 1.9.z is released. (ruby would have to migrate
> together with all its reverse-deps)

As a Ruby person, you really, really don't want an approach that
requires sourceful uploads of every Ruby package out there. And me, as a
release person, really, really don't want an approach that requires all
Ruby packages to migrate at the same time. More on this later (=> ¹).

The decision of whether to allow several ruby 1.9.x versions in the
archive (or a suite) at the same time [in a non-temporary basis] is
orthogonal to the above, really. That decision should depend, solely, on
the answer to this question: is there going to be software that says, "I
work with Ruby 1.9.1, and won't release a version that is compatible
with 1.9.2 in at least six more months"? If the answer is "no" (and I
hope that will be the case), then it really does not make sense to keep
more than one 1.9.x release around (particularly since, at least for
some time, 1.8.x will be around already).

So, returning to the first issue (<= ¹), where all this is going is that
there is going to be a need for a system similar to what Python does
(but fortunately way simpler, since there's no bytecode involved) that
allows for arch:all packages to automatically become available for a
newly installed Ruby version, most likely involving a symlink farm (of
directories wherever possible). [Something akin to arch:all packages
shipping files un /usr/share/ruby1.9/something, and calling a helper
script from maintainer scripts; and the ruby1.9 maintainer scripts
taking care of removing the symlink farm from /usr/lib/ruby/vendor_ruby/1.9.1
to /usr/lib/ruby/vendor_ruby/1.9.2.] That saves you from having to
upload all arch:all packages, and prevents them from having to migrate
together. More about this later (=> ²).

Binary extensions are a bit trickier: their .rb files should go to
/usr/share/ruby1.9/something, and the .so files can be shipped directly
under /usr/lib/ruby/vendor_ruby/1.9.x. I'm not sure if those .so files
are linked against libruby (in which case they'd gain a dependency on
it). However, they must depend on the exact ruby1.9 version, either with
<<, or with a virtual package provided by ruby1.9. And then, a binNMU
just updates them to the new version.

This would still mean that all Ruby packages providing binary extensions
have to migrate at the same time, but I think that should be manageable
(it's what we do with Perl, I think).

There is aproblem with arch:all packages (<= ²), and it's dealing with
Ruby-only packages that need changes to adjust them to a new 1.9.x
release. You wouldn't want to upgrade ruby1.9 without upgrading them,
and something should be devised to prevent that. If they're very few, a
Breaks in ruby1.9 sounds appropriate.

---

And well, this was my dump of comments. I really should have waited to
after Lenny, but I think it's very important that we get things right
for this coming transition (i.e., all the infrastructure should be in
place before starting it).

So, please continue to discuss it, taking all the above into account if
possible, and we'll go from there.

HTH,

--
Adeodato Simó                                     dato at net.com.org.es
Debian Developer                                  adeodato at debian.org
 
Excuse me for thinking a banana-eating contest was about eating a banana!
                -- Paris Geller


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

[Lucas Nussbaum]

On 04/02/09 at 18:29 +0100, Adeodato Simó wrote:
> Hello, Lucas, I hope you don't mind me popping in.

 Not at all :-)

> > Ruby 1.9 is a different story. Upstream decided to version the API,
> > and add a third digit to the library search path:
> > /usr/lib/ruby/1.9.1 instead of /usr/lib/ruby/1.9
> > Because of this, migrating from 1.9.0 (in lenny) to 1.9.1 (will be
> > released upstream soon) won't be simple.
>
> Let's talk this first. The first question is: what is compatible, and
> what is not, between 1.9.x and 1.9.<x+1>. I'll assume, and you'll tell me
> if I'm wrong, that Ruby code that runs fine with eg. 1.9.0, will run
> fine with 1.9.1, with few or none exceptions that will not be possible
> to know in advance. It is very important that we get this information
> right (but I can't imagine it could be any other way).

It's difficult to say. I don't think that there are many
incompatibilities between 1.9.0 and 1.9.1, but, as not so many people
were running 1.9.0, it's difficult to say.

> Binary extensions, OTOH, will most likely need to be rebuilt across
> 1.9.x releases (it'd be awesome if this was not the case, but I don't
> think that's gonna happen). I'll assume, too, that most extensions would
> rebuild just fine without source changes, but that some will need
> adjustements for those "minor API changes" you mention.
>
> > We have two solutions:
> > (A) allow for several ruby 1.9.{x,y} versions to be in the archive and
> > installed at the same time, and do not support upgrades between them.
> > (B) allow only one ruby1.9.{x,y} version to be in a given suite,
> > provide upgrades between 1.9.{x,y}, and do mass-transitions of all
> > ruby libs when a new 1.9.z is released. (ruby would have to migrate
> > together with all its reverse-deps)
>
> As a Ruby person, you really, really don't want an approach that
> requires sourceful uploads of every Ruby package out there. And me, as a
> release person, really, really don't want an approach that requires all
> Ruby packages to migrate at the same time. More on this later (=> ¹).
>
> The decision of whether to allow several ruby 1.9.x versions in the
> archive (or a suite) at the same time [in a non-temporary basis] is
> orthogonal to the above, really. That decision should depend, solely, on
> the answer to this question: is there going to be software that says, "I
> work with Ruby 1.9.1, and won't release a version that is compatible
> with 1.9.2 in at least six more months"? If the answer is "no" (and I
> hope that will be the case), then it really does not make sense to keep
> more than one 1.9.x release around (particularly since, at least for
> some time, 1.8.x will be around already).

The big problem here is that it's usually difficult to second-guess Ruby
upstream developers on their future plans. For example, they broke some
stuff between 1.8.6 and 1.8.7, which was really unexpected.

> So, returning to the first issue (<= ¹), where all this is going is that
> there is going to be a need for a system similar to what Python does
> (but fortunately way simpler, since there's no bytecode involved) that
> allows for arch:all packages to automatically become available for a
> newly installed Ruby version, most likely involving a symlink farm (of
> directories wherever possible). [Something akin to arch:all packages
> shipping files un /usr/share/ruby1.9/something, and calling a helper
> script from maintainer scripts; and the ruby1.9 maintainer scripts
> taking care of removing the symlink farm from /usr/lib/ruby/vendor_ruby/1.9.1
> to /usr/lib/ruby/vendor_ruby/1.9.2.] That saves you from having to
> upload all arch:all packages, and prevents them from having to migrate
> together. More about this later (=> ²).

The problem here is: how do you determine that the package works with
the new version of ruby?

With python, does bytecode recompilation allows to detect most problems?
If not, how are problems found?

Something else to keep in mind is that ruby major versions are quite
rare. 1.9.2 is expected for next january. So whatever we decide, we will
only have to do one (if we release squeeze with 1.9.1, unlikely) or two
migrations during the squeeze release cycle.

I'm not familiar with python packaging. Is everything documented
somewhere?
--
| 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@...

[Dmitry Borodaenko-2]

On Tue, Feb 3, 2009 at 4:24 PM, Lucas Nussbaum <lucas@...> wrote:
> It is not clear yet whether we will ship a ruby1.8 version in squeeze.
> It will depend on how fast Ruby 1.9 is adopted. It is highly
> possible that we decide to remove Ruby 1.8 from squeeze quite late in the
> release process, to avoid supporting it in a stable release.

Considering the argument that 1.9 is a development version that will be released
as 2.0 once it's stabilized, I don't think it would be prudent to remove 1.8
before 2.0 is released, even if 1.9 becomes more popular.

> 1) drop the libruby1.9 package. Replace it with libruby1.9.1.
>   ruby1.9 stays, but depends on libruby1.9.1. Here, "1.9.1" indicates
>   the Ruby API version (or soname), not the version of Ruby. If Ruby
>   1.9.2 stays API-compatible with 1.9.1, this will not be changed
>   (according to the upstream developers).
>
> 2) packages using ruby have to depend on libruby1.9.1. If they also
>   require the interpreter, they need to also depend on libruby1.9.1,
>   to indicate that they depend on this specific version of the API.
>   Depending on ruby1.9 without depending on libruby1.9.1 is an RC bug.

I think this is overcomplicated and confusing. If you don't want parallel
ruby1.9.x versions, staying with current naming scheme works just fine, you will
only have to file an RC bug if a package is actually broken by API upgrade. Most
upstreams (those that are still alive, that is) have already ensured their code
runs on 1.9.0, and most likely will keep it up to date with further API changes
in 1.9.x, so this will reduce the burden on maintianers by an order of magnitude
at least.

> 3) ask library maintainers to install to
>   /usr/lib/ruby/vendor_ruby/1.9.1/ instead of /usr/lib/ruby/1.9.1/,
>   to get out of the mix between standard libs and third-party libs.

Amen to that! Regardless of other changes around Ruby 1.9.x, I think this one
should be mandated by Ruby Policy for all Ruby versions, including 1.8.

While at it, can we also have a version-neutral vendor_ruby directory where we
can install pure-Ruby code that is compatible with all Ruby versions (which, for
example, would be all of my pure-Ruby packages)? Say /usr/lib/ruby/vendor_ruby?

> Open Questions:
> ===============
> 1) Should we allow for several ruby1.9.n versions in the same suite
> at a given time?

I vote "No". Two versions, stable and cutting-edge, will satisfy needs of most
users. People who want stable will stick with 1.8 (I don't expect developers to
drop backwards-compatibility with 1.8 until some time after 2.0 is released,
same as it was with 1.6->1.8 transition), and people who want cutting-edge (and
track unstable) should not be surprised to have some packages break for a while
on an API upgrade (well, a warning in README.Debian of ruby1.9 wouldn't hurt
anyway).

> 2) Library packages naming: change from libxxx-ruby1.9 to something
> else? (would be nice to use that opportunity)
> ruby-xxx? (simpler)
> ruby1.9-xxx? stay with libxxx-ruby1.9?
> libxxx-ruby1.9.1 or ruby1.9.1-xxx? (required if we want to support
> several versions at the same time in the archive)

I think we should stay with libxxx-ruby/libxxx-ruby1.9 convention. "lib" prefix
makes it clear to users (including most of them who know nothing about Ruby)
that the package is a library. If we go with version-neutral vendor_ruby
directory and get rid of most libxxx-ruby1.[89] packages, this would be enough
of a simplification for me.

--
Dmitry Borodaenko


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

[Dmitry Borodaenko-2]

On Thu, Feb 5, 2009 at 1:34 PM, Dmitry Borodaenko <angdraug@...> wrote:
> While at it, can we also have a version-neutral vendor_ruby directory where we
> can install pure-Ruby code that is compatible with all Ruby versions (which, for
> example, would be all of my pure-Ruby packages)? Say /usr/lib/ruby/vendor_ruby?

Oops, I really meant /usr/share/ruby/vendor_ruby here. It's really
past time we stopped violating FHS and moved .rb files out of
/usr/lib.

--
Dmitry Borodaenko


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

[Lucas Nussbaum]

On 05/02/09 at 13:43 +0200, Dmitry Borodaenko wrote:
> On Thu, Feb 5, 2009 at 1:34 PM, Dmitry Borodaenko <angdraug@...> wrote:
> > While at it, can we also have a version-neutral vendor_ruby directory where we
> > can install pure-Ruby code that is compatible with all Ruby versions (which, for
> > example, would be all of my pure-Ruby packages)? Say /usr/lib/ruby/vendor_ruby?
>
> Oops, I really meant /usr/share/ruby/vendor_ruby here. It's really
> past time we stopped violating FHS and moved .rb files out of
> /usr/lib.

This should be pushed upstream, not by Debian.
--
| 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@...

[Paul van Tilburg]

Hello all,

First of all I want to say that Lucas and I decided that Ruby 1.9.1 can
be uploaded independently from what we are currently doing/talking about.
However, we should not bother fixing all the libs until we have clearly
decided on a policy.

Still, if you want to try out stuff, upload to experimental ONLY!
Thanks. :)

On Tue, Feb 03, 2009 at 03:24:42PM +0100, Lucas Nussbaum wrote:

> We (Ruby interpreter maintainers) would like to hear the opinion of
> other people interested in Ruby on our proposed plans for Ruby in
> squeeze.
>
> Ruby 1.8 plans
> ==============
> It is not clear yet whether we will ship a ruby1.8 version in squeeze.
> It will depend on how fast Ruby 1.9 is adopted. It is highly
> possible that we decide to remove Ruby 1.8 from squeeze quite late in the
> release process, to avoid supporting it in a stable release.
>
> In all cases, we don't plan to change the way ruby 1.8 is packaged.

Agreed.  We'll see about that when we get there.
I know of quite a few libs that are not Ruby 1.9-ready.

> Ruby 1.9 plans
> ==============
> Ruby 1.9 is a different story. Upstream decided to version the API,
> and add a third digit to the library search path:
> /usr/lib/ruby/1.9.1 instead of /usr/lib/ruby/1.9
> Because of this, migrating from 1.9.0 (in lenny) to 1.9.1 (will be
> released upstream soon) won't be simple.

For me, the -ruby1.9 stuff was just experimental anyway, given
that 1.9.1 is the first stable 1.9-series release.
I expect we can work this out with dummy packages.

> We have two solutions:
> (A) allow for several ruby 1.9.{x,y} versions to be in the archive and
> installed at the same time, and do not support upgrades between them.

This is going to be a pain and a lot of work.

> (B) allow only one ruby1.9.{x,y} version to be in a given suite,
> provide upgrades between 1.9.{x,y}, and do mass-transitions of all
> ruby libs when a new 1.9.z is released. (ruby would have to migrate
> together with all its reverse-deps)
>
> We would prefer to do (B) since API changes are likely to be minor,
> and new 1.9.z releases are likely not to be too frequent (upstream
> said ~ once a year ; next is due Dec 09 or Jan 10).

Agreed.  I also agree with what Adeodato said about this and have
nothing to add at the moment.
It is obvious we need to examine the different cases and document what
needs to be done to get the current packages in Debian right and also
how new packages need to be set up.

> Proposed solution:
>
> 1) drop the libruby1.9 package. Replace it with libruby1.9.1.
>    ruby1.9 stays, but depends on libruby1.9.1. Here, "1.9.1" indicates
>    the Ruby API version (or soname), not the version of Ruby. If Ruby
>    1.9.2 stays API-compatible with 1.9.1, this will not be changed
>    (according to the upstream developers).
>
> 2) packages using ruby have to depend on libruby1.9.1. If they also
>    require the interpreter, they need to also depend on libruby1.9.1,

This should be: [...] need also depend on ruby1.9.

>    to indicate that they depend on this specific version of the API.
>    Depending on ruby1.9 without depending on libruby1.9.1 is an RC bug.
>
> 3) ask library maintainers to install to
>    /usr/lib/ruby/vendor_ruby/1.9.1/ instead of /usr/lib/ruby/1.9.1/,
>    to get out of the mix between standard libs and third-party libs.

Good idea.  Someone mentioned the /usr/share <> /usr/lib split up.
I am not entirely this cannot be done by the Debian Ruby interpreter
team and needs to be done upstream.  Can we not patch the default
$LOAD_PATH?  Please correct me if I am wrong.

> Migration plans:
> ================
> 1.9.0->1.9.1 migration:
> all packages have to be updated to depend on ruby1.9 and libruby1.9.1,
> and install their files in /usr/lib/ruby/vendor_ruby/1.9.1/
>
> 1.9.1->1.9.2 migration, and later:
> all packages need to be updated to depend on ruby1.9 and libruby1.9.2,
> and install their files in /usr/lib/ruby/vendor_ruby/1.9.2/

Either this or we use this symlink farm mentioned in previous mails.
It might be a good idea to look at Python here.  Maybe someone that
knows how this policy is actually implemented for the Python can
shed a light on this?  Duck? :)

Lucas asked me how to actually handle all this. Do we use the big-bang
approach and get all our libs that are available just for Ruby 1.8
to also provide a -ruby1.9.1 package and see what happens, or...
do we do this incrementally and check every lib thoroughly against
each version and then flag it (and how?)?

I'd say we go for the big bang approach, however... I think we need
some kind of a testing framework.  Something that after building a
package tries to run examples coming with the libraries in some clean
environment against the interpreter versions it is supposed to support.
I do this manually in a non-clean environment now, but I sometimes
forget it and it's a lot of work.

> Open Questions:
> ===============
> 1) Should we allow for several ruby1.9.n versions in the same suite
> at a given time?

Adeodato said the following:
> [...] That decision should depend, solely, on the answer to this
> question:  is there going to be software that says, "I work with Ruby
> 1.9.1, and won't release a version that is compatible with 1.9.2 in at
> least six more months"?  If the answer is "no" (and I hope that will
> be the case), then it really does not make sense to keep more than one
> 1.9.x release around (particularly since, at least for some time,
> 1.8.x will be around already).

I think however, the answer is "yes".  First of all... we have a lot of
libraries that have dead upstream.  Secondly, the weirdest upstream
things seem to happen in the Ruby community.

> 2) Library packages naming: change from libxxx-ruby1.9 to something
> else? (would be nice to use that opportunity)
> ruby-xxx? (simpler)
> ruby1.9-xxx? stay with libxxx-ruby1.9?

This looks nice, but it will involve a wide upgrade path.  It depends on
the momentum we have within the group of Ruby libraries maintainers (I
don't mean the team, I mean everyone).   Do we think we have that?
I don't mind the current Perl naming scheme, but also the Python naming
scheme is nice because it matches more the things upstream uses.

Finally, lets not forget jruby.  We can see this as another interpreter
version instantiation.  So, don't we also need to have libjruby1.1 and
such things?

Paul

--
PhD Student @ Eindhoven                     | email: paulvt@...
University of Technology, The Netherlands   | JID: paul@...
>>> Using the Power of Debian GNU/Linux <<< | GnuPG key ID: 0x50064181


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