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