Candidate new Ruby policy

[Lucas Nussbaum]

[ In addition to debian-ruby@, this mail was sent to several individuals
or lists. If you are not subscribed to debian-ruby@, and receiving this
mail, please subscribe to it. Also, M-F-T set to debian-ruby@ ]

Hi,

This is a candidate summary of a new ruby policy. It doesn't cover all
the details, but try to include all the recent (proposed) changes in
Ruby packaging. This aims at solving several problems, including the
better support of Ruby 1.9.1 and JRuby (and automatic support, for
libraries, for future new versions of Ruby and JRuby).

Note that the ruby-support package mentioned later has not been uploaded
to unstable. Don't hesitate to contact me if you want to help working on
it. Help is badly needed, for testing, and improving CDBS support.
SVN: svn://svn.debian.org/pkg-ruby-extras/tools/ruby-support/trunk
or http://svn.debian.org/viewsvn/pkg-ruby-extras/tools/ruby-support/trunk

Please reply to this mail, even if it's just to say "I'm OK with that".
I would like to avoid moving further will all this without having broad
agreement that this is the way to go.

New rules:
==========
[A] Ruby libraries must support as many as possible of the Ruby versions
    available in Debian. That currently includes Ruby 1.8, Ruby 1.9.0
    (soon 1.9.1), JRuby 1.0, and JRuby 1.1. (Should we drop JRuby 1.0?)
    ruby-support --supported lists the versions that should be
    supported.

[B] Ruby libraries must be installed in "vendor" directories, not mixed
    with the ruby standard library. For Ruby1.8 and 1.9, that means
    using:
      ruby1.8  /usr/lib/ruby/vendor_ruby/1.8
      ruby1.9.0  /usr/lib/ruby/vendor_ruby/1.9.0
      ruby1.9.1  /usr/lib/ruby/vendor_ruby/1.9.1
    For JRuby, a change is needed to create such a directory. No
    "vendor" dir is supported currently.
    ruby-support --supported lists the directories where libraries
    must be installed.

[C] Ruby library package naming policy. Ruby library packages can
    choose between two naming schemes:

    only one ruby-xxxx binary package:
       (mostly for pure-ruby libraries)
       the package contains support for all (or most) of the
       available ruby version. If it's a pure-ruby library, using
       ruby-support to generate a symlink farm is recommended (similar
       to what is done with python-support, i.e symlinks are installed
       for each version of ruby, but there's only one copy of the
       library on the filesystem, to save disk space.)

    several ruby1.9.0-xxxx, ruby1.9.1-xxxx, jruby1.1-xxxx, as well as
    a ruby-xxxx which is a simple dependency package:
       Several packages, each one containing support for a specific
       Ruby version.
       And one ruby-xxxx binary package that will be (mostly) empty,
       and only depend on the current default ruby version.
       This should not be used for pure-ruby libraries (unless there's a
       very good reason not to use the ruby-xxxx scheme).
       This is the recommended way to support native libraries, as it
       avoids adding a dependency on each available Ruby version.

    Other packages can of course be provided, and named
    ruby-xxxx-(doc|examples), but packages proliferation should
    be avoided.

[D] Ruby library source package naming policy. New source packages
    should be named ruby-xxxx, with xxxx being the name of the library.
    Of course, there are lots of special cases here, and there might
    be better names for the source package name of some libraries.
    Existing Ruby libraries can either change name (and adopt the
    ruby-xxxx naming) or keep their existing name.

Something that still needs to be properly documented is the content of
the Depends: field of each kind of Ruby package. I will make sure that,
before we have to start migrating packages, a documentation for that
is provided.

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@...

[Matthew Palmer]

On Sun, Apr 05, 2009 at 09:15:18PM +0200, Lucas Nussbaum wrote:
> New rules:
> ==========
> [A] Ruby libraries must support as many as possible of the Ruby versions
>     available in Debian. That currently includes Ruby 1.8, Ruby 1.9.0
>     (soon 1.9.1), JRuby 1.0, and JRuby 1.1. (Should we drop JRuby 1.0?)
>     ruby-support --supported lists the versions that should be
>     supported.

What counts as "possible"?  What counts as "support"?  It reads like a bit
of a NOOP to me (anything a library can't support it isn't required to
support).

> [B] Ruby libraries must be installed in "vendor" directories, not mixed
>     with the ruby standard library. For Ruby1.8 and 1.9, that means
>     using:
>       ruby1.8  /usr/lib/ruby/vendor_ruby/1.8

Works for me.

> [C] Ruby library package naming policy. Ruby library packages can
>     choose between two naming schemes:

This scheme appears to be a significant departure from current common
practice:

>     only one ruby-xxxx binary package:

$ apt-cache search ruby |grep ^ruby- |wc -l
6

$ apt-cache search ruby |grep -- '-ruby ' |wc -l
176

IOW, the naming scheme *should* be, to my eyes, "one libxxx-ruby binary
package".

>     several ruby1.9.0-xxxx, ruby1.9.1-xxxx, jruby1.1-xxxx, as well as
>     a ruby-xxxx which is a simple dependency package:

Similar to my previous point:

$ apt-cache search ruby1.8 |grep ^ruby1.8- |wc -l  
3

$ apt-cache search ruby |grep -- '-ruby1.8 ' |wc -l
190

So "libxxx-rubyX.Y" would be more common.

Now, if you really do intend that the naming scheme for roughly all
currently extant Ruby libraries be changed, you might want to discuss the
impact of that change with ftpmasters, and I'd *definitely* expect to see a
*very* strong rationale for why the current naming scheme is unworkable and
*needs* to be changed.

> [D] Ruby library source package naming policy. New source packages
>     should be named ruby-xxxx, with xxxx being the name of the library.
>     Of course, there are lots of special cases here, and there might
>     be better names for the source package name of some libraries.
>     Existing Ruby libraries can either change name (and adopt the
>     ruby-xxxx naming) or keep their existing name.

Or, we could just not care particularly, since it makes far more sense to
just stick with whatever upstream has chosen for their library name.

> Something that still needs to be properly documented is the content of
> the Depends: field of each kind of Ruby package. I will make sure that,
> before we have to start migrating packages, a documentation for that
> is provided.

I think this needs to be determined and documented *before* the policy is
adopted, since (as previous attempts in other languages have shown) getting
this right isn't easy, and getting it wrong produces all sorts of pain and
suffering.

> Comments?

I'd like to see a clear rationale for why any of this is actually necessary;
it's not entirely obvious to me what problems you seek to solve, and which
ones will remain unsolved, by this policy.

- Matt


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

[Seo Sanghyeon-3]

2009/4/6 Lucas Nussbaum <lucas@...>:
> [A] Ruby libraries must support as many as possible of the Ruby versions
>    available in Debian. That currently includes Ruby 1.8, Ruby 1.9.0
>    (soon 1.9.1), JRuby 1.0, and JRuby 1.1. (Should we drop JRuby 1.0?)
>    ruby-support --supported lists the versions that should be
>    supported.

I think JRuby 1.0 should be dropped. JRuby 1.2 has been released (but
not yet packaged). And it's not like JRuby 1.0 and 1.1 implement different
languages, as in the case of Ruby 1.8 and 1.9.

--
Seo Sanghyeon


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

[Lucas Nussbaum]

On 06/04/09 at 06:31 +1000, Matthew Palmer wrote:

> On Sun, Apr 05, 2009 at 09:15:18PM +0200, Lucas Nussbaum wrote:
> > New rules:
> > ==========
> > [A] Ruby libraries must support as many as possible of the Ruby versions
> >     available in Debian. That currently includes Ruby 1.8, Ruby 1.9.0
> >     (soon 1.9.1), JRuby 1.0, and JRuby 1.1. (Should we drop JRuby 1.0?)
> >     ruby-support --supported lists the versions that should be
> >     supported.
>
> What counts as "possible"?  What counts as "support"?  It reads like a bit
> of a NOOP to me (anything a library can't support it isn't required to
> support).

Of course it's not binding. It's more like a position statement that a
"good" library package should support all available ruby version, and
that supporting only Ruby 1.8 (or Ruby 1.8 and 1.9) is considered "not
good enough".

> > [C] Ruby library package naming policy. Ruby library packages can
> >     choose between two naming schemes:
>
> This scheme appears to be a significant departure from current common
> practice:
[...]
> Now, if you really do intend that the naming scheme for roughly all
> currently extant Ruby libraries be changed, you might want to discuss the
> impact of that change with ftpmasters, and I'd *definitely* expect to see a
> *very* strong rationale for why the current naming scheme is unworkable and
> *needs* to be changed.

For pure-ruby libraries, we need to move away from manually providing
support for all ruby versions. It is not manageable to do sourceful
uploads of all libraries each time a new major ruby version is released.
That's what ruby-support provides.

But this new policy will require sourceful uploads of all library
packages, with a change in the number of binary packages (so we would
have to go through NEW anyway), so it is a good idea to pass as many
large-scale changes as possible at the same time. Like several others,
I'm not a huge fan of the libxxx-rubyxxx naming scheme, and moving to a
pythonish scheme, and away from a perlish one, seems logical since
ruby-support is just ruby's version of python-support.

> > [D] Ruby library source package naming policy. New source packages
> >     should be named ruby-xxxx, with xxxx being the name of the library.
> >     Of course, there are lots of special cases here, and there might
> >     be better names for the source package name of some libraries.
> >     Existing Ruby libraries can either change name (and adopt the
> >     ruby-xxxx naming) or keep their existing name.
>
> Or, we could just not care particularly, since it makes far more sense to
> just stick with whatever upstream has chosen for their library name.

Isn't that what I wrote? The goal of this point is to provide a default
choice that is reasonable, for packages where there's no good default. But:
> >     Of course, there are lots of special cases here, and there might
> >     be better names for the source package name of some libraries.


> > Something that still needs to be properly documented is the content of
> > the Depends: field of each kind of Ruby package. I will make sure that,
> > before we have to start migrating packages, a documentation for that
> > is provided.
>
> I think this needs to be determined and documented *before* the policy is
> adopted, since (as previous attempts in other languages have shown) getting
> this right isn't easy, and getting it wrong produces all sorts of pain and
> suffering.

Sure, please help :-)

> > Comments?
>
> I'd like to see a clear rationale for why any of this is actually necessary;
> it's not entirely obvious to me what problems you seek to solve, and which
> ones will remain unsolved, by this policy.

I hope that the above replies clarify a bit ; feel free to ask more
questions.
--
| 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 06/04/09 at 10:47 +0900, Seo Sanghyeon wrote:

> 2009/4/6 Lucas Nussbaum <lucas@...>:
> > [A] Ruby libraries must support as many as possible of the Ruby versions
> >    available in Debian. That currently includes Ruby 1.8, Ruby 1.9.0
> >    (soon 1.9.1), JRuby 1.0, and JRuby 1.1. (Should we drop JRuby 1.0?)
> >    ruby-support --supported lists the versions that should be
> >    supported.
>
> I think JRuby 1.0 should be dropped. JRuby 1.2 has been released (but
> not yet packaged). And it's not like JRuby 1.0 and 1.1 implement different
> languages, as in the case of Ruby 1.8 and 1.9.

I'm not sure of the API changes between jruby 1.1 and 1.2. I had the
impression that jruby 1.2 was jruby's version of ruby 1.9? (with
similar API changes?)
--
| 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@...

[Seo Sanghyeon-3]

2009/4/6 Lucas Nussbaum <lucas@...>:
> I'm not sure of the API changes between jruby 1.1 and 1.2. I had the
> impression that jruby 1.2 was jruby's version of ruby 1.9? (with
> similar API changes?)

No, this is not true. JRuby 1.2 implements Ruby 1.8 language, by default.
There *is* a support for Ruby 1.9 language, but this support needs
to be explicitly asked by --1.9 command line option.

--
Seo Sanghyeon


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

[Lucas Nussbaum]

On 06/04/09 at 14:55 +0900, Seo Sanghyeon wrote:
> 2009/4/6 Lucas Nussbaum <lucas@...>:
> > I'm not sure of the API changes between jruby 1.1 and 1.2. I had the
> > impression that jruby 1.2 was jruby's version of ruby 1.9? (with
> > similar API changes?)
>
> No, this is not true. JRuby 1.2 implements Ruby 1.8 language, by default.
> There *is* a support for Ruby 1.9 language, but this support needs
> to be explicitly asked by --1.9 command line option.

OK. Do you know what the load path look like for jruby 1.2?

Is there a vendor dir now?

If you have one locally compiled, try jruby1.2 -e 'p $:'
--
| 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@...

[Seo Sanghyeon-3]

2009/4/6 Lucas Nussbaum <lucas@...>:
> OK. Do you know what the load path look like for jruby 1.2?

Exactly same has JRuby 1.1.

> Is there a vendor dir now?

No.

--
Seo Sanghyeon


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

[Dmitry Borodaenko-2]

On Mon, Apr 6, 2009 at 8:22 AM, Lucas Nussbaum <lucas@...> wrote:
>> > [A] Ruby libraries must support as many as possible of the Ruby versions
>> >     available in Debian. That currently includes Ruby 1.8, Ruby 1.9.0
>> >     (soon 1.9.1), JRuby 1.0, and JRuby 1.1. (Should we drop JRuby 1.0?)
>> >     ruby-support --supported lists the versions that should be
>> >     supported.

How do I add JRuby support to my packages?

$ grep-aptavail -sPackage -FDepends jruby|wc -l
0

I think something along the lines of the hello package, but following
all the requirements and recommendations of the new Ruby policy, would
help people figure out how to migrate.

Also, is there any reason that Rubinius and Cardinal are not in Debian,
or is it just because noone is interested in trying them out?

>> > [C] Ruby library package naming policy. Ruby library packages can
>> >     choose between two naming schemes:
>>
>> This scheme appears to be a significant departure from current common
>> practice:
> [...]
>> Now, if you really do intend that the naming scheme for roughly all
>> currently extant Ruby libraries be changed, you might want to discuss the
>> impact of that change with ftpmasters, and I'd *definitely* expect to see a
>> *very* strong rationale for why the current naming scheme is unworkable and
>> *needs* to be changed.
>
> For pure-ruby libraries, we need to move away from manually providing
> support for all ruby versions. It is not manageable to do sourceful
> uploads of all libraries each time a new major ruby version is released.
> That's what ruby-support provides.
>
> But this new policy will require sourceful uploads of all library
> packages, with a change in the number of binary packages (so we would
> have to go through NEW anyway), so it is a good idea to pass as many
> large-scale changes as possible at the same time. Like several others,
> I'm not a huge fan of the libxxx-rubyxxx naming scheme, and moving to a
> pythonish scheme, and away from a perlish one, seems logical since
> ruby-support is just ruby's version of python-support.

I think the number of sourceful uploads is not the only problem that may
be caused by a massive renaming of Ruby library packages. What will be
the impact on reverse dendencies of all the renamed libraries? Can we
downgrade this naming change from requirement to recommendation,
allowing but discouraging the old naming scheme?

Is a single pure Ruby package for all Ruby versions the only reason for
sourceful uploads of all Ruby library packages? Wouldn't a Ruby
interpreter package that adds support for this policy also be
backwards-compatible with packages following the old policy? This would
allow to migrate packages one by one, instead of a painful
mass-migration.

Wait a second, why don't we use /usr/lib/ruby/vendor_ruby (which is
already included in $LOAD_PATH for ruby1.8 and ruby1.9? We will have to
patch vendor_ruby support into jruby anyway, so why don't we point it
there as well, and mandate this in the policy? With this, we won't even
need a symlink farm for pure-ruby libraries, all we need is to tell
people to put their .rb files there.

--
Dmitry Borodaenko


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

[Lucas Nussbaum]

On 06/04/09 at 19:56 +0300, Dmitry Borodaenko wrote:
> On Mon, Apr 6, 2009 at 8:22 AM, Lucas Nussbaum <lucas@...> wrote:
> >> > [A] Ruby libraries must support as many as possible of the Ruby versions
> >> >     available in Debian. That currently includes Ruby 1.8, Ruby 1.9.0
> >> >     (soon 1.9.1), JRuby 1.0, and JRuby 1.1. (Should we drop JRuby 1.0?)
> >> >     ruby-support --supported lists the versions that should be
> >> >     supported.
>
> How do I add JRuby support to my packages?

Currently, you would have to also install the files into jruby's load
path, preferably in a different binary package.

> $ grep-aptavail -sPackage -FDepends jruby|wc -l
> 0

Yeah, that's the problem.

> I think something along the lines of the hello package, but following
> all the requirements and recommendations of the new Ruby policy, would
> help people figure out how to migrate.

Sure. But first, we have two agree on which goals we want to reach.

> Also, is there any reason that Rubinius and Cardinal are not in Debian,
> or is it just because noone is interested in trying them out?

Apparently noone is interested. Once ruby-support is in Debian and
working, it should be easy to automatically add rubinius support to
packages, though.

> >> > [C] Ruby library package naming policy. Ruby library packages can
> >> >     choose between two naming schemes:
> >>
> >> This scheme appears to be a significant departure from current common
> >> practice:
> > [...]
> >> Now, if you really do intend that the naming scheme for roughly all
> >> currently extant Ruby libraries be changed, you might want to discuss the
> >> impact of that change with ftpmasters, and I'd *definitely* expect to see a
> >> *very* strong rationale for why the current naming scheme is unworkable and
> >> *needs* to be changed.
> >
> > For pure-ruby libraries, we need to move away from manually providing
> > support for all ruby versions. It is not manageable to do sourceful
> > uploads of all libraries each time a new major ruby version is released.
> > That's what ruby-support provides.
> >
> > But this new policy will require sourceful uploads of all library
> > packages, with a change in the number of binary packages (so we would
> > have to go through NEW anyway), so it is a good idea to pass as many
> > large-scale changes as possible at the same time. Like several others,
> > I'm not a huge fan of the libxxx-rubyxxx naming scheme, and moving to a
> > pythonish scheme, and away from a perlish one, seems logical since
> > ruby-support is just ruby's version of python-support.
>
> I think the number of sourceful uploads is not the only problem that may
> be caused by a massive renaming of Ruby library packages. What will be
> the impact on reverse dendencies of all the renamed libraries?

90% of the reverse dependencies will probably also require changes,
because they are also ruby packages. I don't think that there are that
many packages that:
(A) depend on ruby libraries
(B) are not ruby libraries themselves

> Can we downgrade this naming change from requirement to
> recommendation, allowing but discouraging the old naming scheme?

No. Either we rename all packages, or we rename none of them. Having two
different naming schemes for Ruby packages will be a nightmare. If we
really really want to minimize the number of changed packages, we could
keep the current libxxx-rubyxxx scheme, and have:
- libxxx-ruby for pure-ruby libs
- libxxx-ruby, libxxx-ruby1.8, libxxx-ruby1.9, etc. for native libs.
However, if we do that, it will be much harder to track which packages
have been migrated or not.

> Is a single pure Ruby package for all Ruby versions the only reason for
> sourceful uploads of all Ruby library packages?

Well, isn't that enough? :-)

> Wouldn't a Ruby
> interpreter package that adds support for this policy also be
> backwards-compatible with packages following the old policy?

What we could do is install all pure-ruby libs in /usr/lib/debian-ruby
(or whatever), and add /usr/lib/debian-ruby to the load path of all
interpreter packages.
However, if we do that:
(A) we completely diverge from upstream
(B) we won't be able to deal with packages that are not supported by a
specific ruby version, or that require changes between ruby versions

I really don't want to go towards that path.

> This would
> allow to migrate packages one by one, instead of a painful
> mass-migration.
>
> Wait a second, why don't we use /usr/lib/ruby/vendor_ruby (which is
> already included in $LOAD_PATH for ruby1.8 and ruby1.9? We will have to
> patch vendor_ruby support into jruby anyway, so why don't we point it
> there as well, and mandate this in the policy? With this, we won't even
> need a symlink farm for pure-ruby libraries, all we need is to tell
> people to put their .rb files there.

That's what I just said. That means ignoring all API problems. We would
have to patch Ruby libraries so that they work with all Ruby versions at
the same time. (possibly testing the running ruby version so that we
know which version of the code to use)

How much time would you be willing to invest on this? Basically, all of
this boils down to "who wants to do the (boring) work?"
--
| 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@...

[Sebastien Delafond]

On 2009-04-06, Seo Sanghyeon <sanxiyn@...> wrote:
> I think JRuby 1.0 should be dropped. JRuby 1.2 has been released
> (but not yet packaged).

I agree, especially as I plan on uploading jruby1.2 to sid in the next
couple of days.

Cheers,

--Seb


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

[Sebastien Delafond]

On 2009-04-05, Lucas Nussbaum <lucas@...> wrote:

> [B] Ruby libraries must be installed in "vendor" directories, not mixed
>     with the ruby standard library. For Ruby1.8 and 1.9, that means
>     using:
>       ruby1.8  /usr/lib/ruby/vendor_ruby/1.8
>       ruby1.9.0  /usr/lib/ruby/vendor_ruby/1.9.0
>       ruby1.9.1  /usr/lib/ruby/vendor_ruby/1.9.1
>     For JRuby, a change is needed to create such a directory. No
>     "vendor" dir is supported currently.
>     ruby-support --supported lists the directories where libraries
>     must be installed.

adding a "vendor" dir to jruby is certainly an option, and I'd be
happy to put this into the 1.2.0 upload that I'm working on these
days.

Cheers,

--Seb, sorry for jumping late into this thread


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

[Sebastien Delafond]

On 2009-04-05, Lucas Nussbaum <lucas@...> wrote:
> [A] Ruby libraries must support as many as possible of the Ruby versions
>     available in Debian. That currently includes Ruby 1.8, Ruby 1.9.0
>     (soon 1.9.1), JRuby 1.0, and JRuby 1.1. (Should we drop JRuby 1.0?)
>     ruby-support --supported lists the versions that should be
>     supported.

sure.

> [B] Ruby libraries must be installed in "vendor" directories, not mixed
>     with the ruby standard library. For Ruby1.8 and 1.9, that means
>     using:
>       ruby1.8  /usr/lib/ruby/vendor_ruby/1.8
>       ruby1.9.0  /usr/lib/ruby/vendor_ruby/1.9.0
>       ruby1.9.1  /usr/lib/ruby/vendor_ruby/1.9.1
>     For JRuby, a change is needed to create such a directory. No
>     "vendor" dir is supported currently.

sure.

> [C] Ruby library package naming policy. Ruby library packages can
>     choose between two naming schemes:
>     [...]

as it's already been mentioned in this thread, most other ruby
packages seem to be named xxxx-ruby; the principle of least effort
would have me favor the naming schema that involves as little renaming
as possible, but I will of course gladly bow to the majority's
decision, and rename all my packages if necessary.

Regards,

--Seb


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

[Gunnar Wolf]

Lucas Nussbaum dijo [Sun, Apr 05, 2009 at 09:15:18PM +0200]:
> (...)
> Please reply to this mail, even if it's just to say "I'm OK with that".
> I would like to avoid moving further will all this without having broad
> agreement that this is the way to go.

<AOL>OK!</AOL>

> New rules:
> ==========

In general, yes, it looks like a very positive change. I feel the
current libfoo-ruby/libfoo-ruby1.8/libfoo-ruby1.9/libfoo-ruby-doc
split is unclear and dirty when not needed, and creates ugly
transition pains. Thanks for pushing this change!

> [A] Ruby libraries must support as many as possible of the Ruby versions
>     available in Debian. That currently includes Ruby 1.8, Ruby 1.9.0
>     (soon 1.9.1), JRuby 1.0, and JRuby 1.1. (Should we drop JRuby 1.0?)
>     ruby-support --supported lists the versions that should be
>     supported.

See #522996 - AFAICT, while for some time there can be more than one
JRuby in testing/unstable, we should aim to having only one version in
stable releases (and reducing the time we have two
simultaneous). While I am not a JRuby user and have no idea on its
stability, keeping 1.0 around does not seem like getting us anything.

> (snip)
> [C] Ruby library package naming policy. Ruby library packages can
>     choose between two naming schemes:
>
>     only one ruby-xxxx binary package:
>        (...)
>     several ruby1.9.0-xxxx, ruby1.9.1-xxxx, jruby1.1-xxxx, as well as
>     a ruby-xxxx which is a simple dependency package:
>        (...)
>     Other packages can of course be provided, and named
>     ruby-xxxx-(doc|examples), but packages proliferation should
>     be avoided.

And of course, we should make a point on revising all current
packages, as (I hope) most of them will be converted to the first
scheme.

> [D] Ruby library source package naming policy. New source packages
>     should be named ruby-xxxx, with xxxx being the name of the library.
>     Of course, there are lots of special cases here, and there might
>     be better names for the source package name of some libraries.

I don't have a strong preference for current libxxxx-ruby scheme over
this one or otherwise, although moving everything to ruby-xxxx will
require dependency information to be updated all over the archive,
while leaving libxxxx-ruby could leave them all valid. Why are you
proposing this change?

>     Existing Ruby libraries can either change name (and adopt the
>     ruby-xxxx naming) or keep their existing name.

I understand this is to ease the pain - but it gets us to an
inconsistent state. I'd rather encourage people to do the naming
switch if one is to happen, if for nothing else, to keep users from
having two naming variations to search on.

Thanks,

--
Gunnar Wolf - gwolf@... - ([phone] / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF

[Dmitry Borodaenko-2]

On Tue, Apr 7, 2009 at 12:14 AM, Lucas Nussbaum
<lucas@...> wrote:
>> How do I add JRuby support to my packages?
> Currently, you would have to also install the files into jruby's load
> path, preferably in a different binary package.

What about native libs? Do they have to have Java replacement for their
C code? (Of my packages, only Redcloth has that.) Or is there a way to
build and link .so libraries agaist JRuby?

> 90% of the reverse dependencies will probably also require changes,
> because they are also ruby packages. I don't think that there are that
> many packages that:
> (A) depend on ruby libraries
> (B) are not ruby libraries themselves

True.

>> Can we downgrade this naming change from requirement to
>> recommendation, allowing but discouraging the old naming scheme?
> No. Either we rename all packages, or we rename none of them. Having
> two different naming schemes for Ruby packages will be a nightmare.

Fair enough.

> If we really really want to minimize the number of changed packages,
> we could keep the current libxxx-rubyxxx scheme, and have:
> - libxxx-ruby for pure-ruby libs
> - libxxx-ruby, libxxx-ruby1.8, libxxx-ruby1.9, etc. for native libs.
> However, if we do that, it will be much harder to track which packages
> have been migrated or not.

Ok, then that's the second reason for sourceful uploads: to make
migrated packages stand out more by renaming them. Although, for
argument's sake, there might be less radical ways of tracking migrated
packages (e.g. Depends: ruby-support (>= 1.0)).

>> Is a single pure Ruby package for all Ruby versions the only reason
>> for sourceful uploads of all Ruby library packages?
> Well, isn't that enough? :-)

That's enough for a sourceful upload of _a_ package, but not necessarily
for a burn-all-bridges no-backwards-compatibility mass upload of _all_
Ruby packages.

>> Wouldn't a Ruby interpreter package that adds support for this policy
>> also be backwards-compatible with packages following the old policy?
> What we could do is install all pure-ruby libs in /usr/lib/debian-ruby
> (or whatever), and add /usr/lib/debian-ruby to the load path of all
> interpreter packages.
> However, if we do that:
> (A) we completely diverge from upstream

Not if we use /usr/lib/ruby/vendor_ruby which is already supported by
upstream.

> (B) we won't be able to deal with packages that are not supported by a
> specific ruby version, or that require changes between ruby versions
>
> I really don't want to go towards that path.

I tried to address this concern below.

>> This would allow to migrate packages one by one, instead of a painful
>> mass-migration.
>>
>> Wait a second, why don't we use /usr/lib/ruby/vendor_ruby (which is
>> already included in $LOAD_PATH for ruby1.8 and ruby1.9? We will have
>> to patch vendor_ruby support into jruby anyway, so why don't we point
>> it there as well, and mandate this in the policy? With this, we won't
>> even need a symlink farm for pure-ruby libraries, all we need is to
>> tell people to put their .rb files there.
>
> That's what I just said. That means ignoring all API problems. We
> would have to patch Ruby libraries so that they work with all Ruby
> versions at the same time. (possibly testing the running ruby version
> so that we know which version of the code to use)
>
> How much time would you be willing to invest on this? Basically, all
> of this boils down to "who wants to do the (boring) work?"

What I'm trying to figure out is a way to reduce the amount of work for
everyone involved, not to increase it. Migration will require
non-trivial changes to over 200 packages. Mass migration means that we
can't wait for all maintainers to update the packages and that someone
has to do a lot of NMUs, to reduce the time when Ruby in Debian will be
broken.

Unless ruby-support auto-magically detects API compatibility with all
supported Ruby interpreters, the work of testing packages against
interpreters is not going anywere and still needs to be done, regardless
of the approach we take.

If we do symlink farms, the packages that will turn out to have API
problems will not install the symlinks for incompatible interpreters.

- Pro: users who attempt to use the library with a wrong interpreter
  will immediately get LoadError.

- Contra: we have to detect API compatibility upfront (for 200 packages)
  and change the packaging every time compatibility status changes;
  users who want to fix and test API problems in the library have to do
  their own packaging first, or resort to non-Debian means of installing
  the library.

If we do single vendor_ruby in $LOAD_PATH of all interpreters, the
pure-ruby libraries with API problems will still be available for
incompatible interpreters.

- Pro: we only have to fix the packages which are actually broken, we
  don't have to change anything if API issues are fixed upstream, users
  can try out the library with all interpreters out of the box and
  report and/or fix the API issues if they want.

- Contra: API compatibility status is not reflected explicitly by the
  package, users who attempt to use the library with a wrong interpreter
  will get (potentially weird and/or intermittent) problems at run time.

The latter sounds pretty bad, but in reality it's quite manageable.

First of all, we already have a known-good interpreter that is
compatible with all our Ruby library packages, and, by no coincidence,
this interpreter is the default Ruby interpreter installed when you
apt-get install ruby. I mean, of course, ruby1.8. This means that people
who just need a piece of software that happens to be written in Ruby,
and who don't want to know anything about different Ruby interpreters
and API compatiblity issues, will not install non-default interpreters
and will not get those scary weird intermittent API-induced bugs.

Users who do care about alternative interpreters are much more likely to
read the interpreter's README.Debian, where we can warn about possible
API compatibility issues, instruct how and where to report these issues
(raise a normal bug against a specific library package), and point to
interpreter's documentation which hopefully explains what are the
typical exceptions and how they should be addressed. We can even rub
this in via a debconf screen.

At some point we will want to upgrade ruby-default from ruby1.8 to
ruby1.9.x, and that will be the earliest point when we will really need
that API compatibility data. By that time, most of the libraries should
already be fixed upstream, and even if we still need to do mass API
compatibility tests, the number of packages to be tested will be greatly
reduced by excluding the packages which are explicitly documented to be
compatible with Ruby 1.9.x (in changelog entries or bugs in Debian BTS
or both). Not to mention that such tests wouldn't need any changes to
the packages whatsoever.

--
Dmitry Borodaenko


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

[Lucas Nussbaum]

On 08/04/09 at 19:40 +0300, Dmitry Borodaenko wrote:

> What I'm trying to figure out is a way to reduce the amount of work for
> everyone involved, not to increase it. Migration will require
> non-trivial changes to over 200 packages. Mass migration means that we
> can't wait for all maintainers to update the packages and that someone
> has to do a lot of NMUs, to reduce the time when Ruby in Debian will be
> broken.
>
> Unless ruby-support auto-magically detects API compatibility with all
> supported Ruby interpreters, the work of testing packages against
> interpreters is not going anywere and still needs to be done, regardless
> of the approach we take.
>
> If we do symlink farms, the packages that will turn out to have API
> problems will not install the symlinks for incompatible interpreters.
>
> - Pro: users who attempt to use the library with a wrong interpreter
>   will immediately get LoadError.
>
> - Contra: we have to detect API compatibility upfront (for 200 packages)
>   and change the packaging every time compatibility status changes;
>   users who want to fix and test API problems in the library have to do
>   their own packaging first, or resort to non-Debian means of installing
>   the library.
>
> If we do single vendor_ruby in $LOAD_PATH of all interpreters, the
> pure-ruby libraries with API problems will still be available for
> incompatible interpreters.
>
> - Pro: we only have to fix the packages which are actually broken, we
>   don't have to change anything if API issues are fixed upstream, users
>   can try out the library with all interpreters out of the box and
>   report and/or fix the API issues if they want.
>
> - Contra: API compatibility status is not reflected explicitly by the
>   package, users who attempt to use the library with a wrong interpreter
>   will get (potentially weird and/or intermittent) problems at run time.
>
> The latter sounds pretty bad, but in reality it's quite manageable.
>
> First of all, we already have a known-good interpreter that is
> compatible with all our Ruby library packages, and, by no coincidence,
> this interpreter is the default Ruby interpreter installed when you
> apt-get install ruby. I mean, of course, ruby1.8. This means that people
> who just need a piece of software that happens to be written in Ruby,
> and who don't want to know anything about different Ruby interpreters
> and API compatiblity issues, will not install non-default interpreters
> and will not get those scary weird intermittent API-induced bugs.
>
> Users who do care about alternative interpreters are much more likely to
> read the interpreter's README.Debian, where we can warn about possible
> API compatibility issues, instruct how and where to report these issues
> (raise a normal bug against a specific library package), and point to
> interpreter's documentation which hopefully explains what are the
> typical exceptions and how they should be addressed. We can even rub
> this in via a debconf screen.
>
> At some point we will want to upgrade ruby-default from ruby1.8 to
> ruby1.9.x, and that will be the earliest point when we will really need
> that API compatibility data. By that time, most of the libraries should
> already be fixed upstream, and even if we still need to do mass API
> compatibility tests, the number of packages to be tested will be greatly
> reduced by excluding the packages which are explicitly documented to be
> compatible with Ruby 1.9.x (in changelog entries or bugs in Debian BTS
> or both). Not to mention that such tests wouldn't need any changes to
> the packages whatsoever.

That's a rather fair summary of the problem, but your are missing one
half of the issue.

1) there are libraries which aren't compatible with Ruby1.9 yet. That's
addressed by your summary.

2) there are libraries which are no longer compatible with Ruby1.8,
because they use new features in Ruby1.9. Such libraries might become
more and more common. And even if Ruby1.9 becomes the default Ruby
version in Debian, we might want to keep Ruby1.8 around for some time.

I don't really like the perspective of having no simple way to exclude a
library from being loaded with a given version of Ruby.
--
| 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 08/04/09 at 11:30 -0500, Gunnar Wolf wrote:

> > [D] Ruby library source package naming policy. New source packages
> >     should be named ruby-xxxx, with xxxx being the name of the library.
> >     Of course, there are lots of special cases here, and there might
> >     be better names for the source package name of some libraries.
>
> I don't have a strong preference for current libxxxx-ruby scheme over
> this one or otherwise, although moving everything to ruby-xxxx will
> require dependency information to be updated all over the archive,
> while leaving libxxxx-ruby could leave them all valid. Why are you
> proposing this change?
>
> >     Existing Ruby libraries can either change name (and adopt the
> >     ruby-xxxx naming) or keep their existing name.
>
> I understand this is to ease the pain - but it gets us to an
> inconsistent state. I'd rather encourage people to do the naming
> switch if one is to happen, if for nothing else, to keep users from
> having two naming variations to search on.

The [D] point of the policy was for source packages, not binary
packages. The point is to provide a sane default choice (ruby-xxx) for
new packages. For existing packages, I don't really care about what is
done, and having different naming schemes for source packages
doesn't sound too harmful (it's already the case). But having new source
packages named libxxx-ruby, while their binary packages will be named
ruby(|xxx)-xxx, doesn't sound like a good idea.
--
| 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@...

[Michael Schutte-2]

Hey everyone,

On Sun, Apr 05, 2009 at 09:15:18PM +0200, Lucas Nussbaum wrote:
> Please reply to this mail, even if it's just to say "I'm OK with that".
> I would like to avoid moving further will all this without having broad
> agreement that this is the way to go.

I’m in favour. :-)

> [C] Ruby library package naming policy. Ruby library packages can
>     choose between two naming schemes:

I personally don’t like the idea of hundreds of transitional packages
floating around for an entire release cycle.  The “getting closer to
Python” and “tracking the migration” arguments both seem a bit weak to
me to justify such a high-impact change, considering that the current
naming scheme isn’t really broken.

>     several ruby1.9.0-xxxx, ruby1.9.1-xxxx, jruby1.1-xxxx, as well as
>     a ruby-xxxx which is a simple dependency package:
>        Several packages, each one containing support for a specific
>        Ruby version.
>        And one ruby-xxxx binary package that will be (mostly) empty,
>        and only depend on the current default ruby version.
>        This should not be used for pure-ruby libraries (unless there's a
>        very good reason not to use the ruby-xxxx scheme).
>        This is the recommended way to support native libraries, as it
>        avoids adding a dependency on each available Ruby version.

This requires sourceful uploads of all the native-lib packages whenever
a new version of Ruby is introduced, right?  ruby-support’s README file
states that the control files could be automatically generated at build
time to facilitate binNMUs.  I like this idea, is it still up for
discussion?

Cheers,
--
Michael Schutte <michi@...>

[Lucas Nussbaum]

On 08/04/09 at 20:29 +0200, Michael Schutte wrote:

> Hey everyone,
>
> On Sun, Apr 05, 2009 at 09:15:18PM +0200, Lucas Nussbaum wrote:
> > Please reply to this mail, even if it's just to say "I'm OK with that".
> > I would like to avoid moving further will all this without having broad
> > agreement that this is the way to go.
>
> I’m in favour. :-)
>
> > [C] Ruby library package naming policy. Ruby library packages can
> >     choose between two naming schemes:
>
> I personally don’t like the idea of hundreds of transitional packages
> floating around for an entire release cycle.  The “getting closer to
> Python” and “tracking the migration” arguments both seem a bit weak to
> me to justify such a high-impact change, considering that the current
> naming scheme isn’t really broken.
>
> >     several ruby1.9.0-xxxx, ruby1.9.1-xxxx, jruby1.1-xxxx, as well as
> >     a ruby-xxxx which is a simple dependency package:
> >        Several packages, each one containing support for a specific
> >        Ruby version.
> >        And one ruby-xxxx binary package that will be (mostly) empty,
> >        and only depend on the current default ruby version.
> >        This should not be used for pure-ruby libraries (unless there's a
> >        very good reason not to use the ruby-xxxx scheme).
> >        This is the recommended way to support native libraries, as it
> >        avoids adding a dependency on each available Ruby version.
>
> This requires sourceful uploads of all the native-lib packages whenever
> a new version of Ruby is introduced, right?  ruby-support’s README file
> states that the control files could be automatically generated at build
> time to facilitate binNMUs.  I like this idea, is it still up for
> discussion?

It is, but requires a lot of work, which hasn't been done yet.

My current plan is to evaluate the current state of Ruby packages, to
get some real numbers on the number of pure-ruby and native packages.

Then, as a first step, I will probably push for a ruby-support version
that only deals with pure-ruby libs, and leave native libs for later (so
we would have to deal with them manually). The problem is that, while we
have a good idea of what happens with pure-ruby libs when supporting
multiple ruby versions, we have no experience on supporting multiple
ruby versions with native libs.
--
| 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@...

[Gunnar Wolf]

Lucas Nussbaum dijo [Wed, Apr 08, 2009 at 07:06:39PM +0200]:

> > >     Existing Ruby libraries can either change name (and adopt the
> > >     ruby-xxxx naming) or keep their existing name.
> >
> > I understand this is to ease the pain - but it gets us to an
> > inconsistent state. I'd rather encourage people to do the naming
> > switch if one is to happen, if for nothing else, to keep users from
> > having two naming variations to search on.
>
> The [D] point of the policy was for source packages, not binary
> packages. The point is to provide a sane default choice (ruby-xxx) for
> new packages. For existing packages, I don't really care about what is
> done, and having different naming schemes for source packages
> doesn't sound too harmful (it's already the case). But having new source
> packages named libxxx-ruby, while their binary packages will be named
> ruby(|xxx)-xxx, doesn't sound like a good idea.

Umh... Still, why are you proposing the change from libxxx-ruby to
ruby(|xxx)-xxx for (either source or binary) packages? I completely
agree they should be consistently named, but libxxx-ruby is much more
widespread nowadays.

And I'd add that existing packages should be homogeneized as much as
possible, even if it means going again through NEW.

Greetings,

--
Gunnar Wolf - gwolf@... - ([phone] / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


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