[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Candidate new Ruby policy

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

Michael Schutte <michi@uiae.at>

Attachment: signature.asc
Description: Digital signature

Reply to: