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 | [email protected] http://www.lucas-nussbaum.net/ | | jabber: [email protected] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
