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@uiae.at>
Attachment:
signature.asc
Description: Digital signature