Re: Candidate new Ruby policy
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
Reply to: