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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
