Re: Candidate new Ruby policy
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@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |
Reply to: