On Tue, Mar 27, 2012 at 11:50:21AM +0200, Cédric Boutillier wrote: > I wrote a first draft available on gobby.debian.org, under > Teams/RubyExtras/transition_to_new_policy.txt. Before more polishing, > could you please read/review/criticise/edit/improve (constructively :D)? I thank very much Gunnar Wolf who reviewed and improved that text. I would like very much to get other reviews, especially from people more involved, and for a longer period of time in the team, and in Debian in general. Would you like to (have me) add/modify/remove something? For completeness, I reproduce the proposition below. Thanks! Cédric --------------------8<---------------------------------------- Hi! In less than three months, Wheezy will be frozen. One of the goals of the Ruby Team for Wheezy is to try to push as far as possible the transition to a new policy for Ruby library. The Ruby Extras Maintainers have put a lot of effort on this goal, converting (most of) the packages they maintain to this policy. The success of this effort can be measured on the graph [0]. 0: http://pkg-ruby-extras.alioth.debian.org/wheezy/ The data used for this graph taken into account *all* Ruby libraries contained in Debian, and not only those maintained by the Ruby Extras packaging team. In order to improve these statitistics and finish the transition, we would like to encourage all maintainers of Ruby packages in Debian to update their packages to reflect these changes. These changes concern three different aspects: the package naming convention, the path where libraries are installed, and the execution of test suites at build time. These aspects are briefly described below and detailed in the draft of the Ruby policy [1]. If you maintain Ruby packages, please read until the end ;). 1: http://anonscm.debian.org/gitweb/?p=pkg-ruby-extras/ruby-policy.git;a=summary Naming conventions ------------------ The source packages libfoo-ruby should be renamed ruby-foo. If these packages provide extensions needing to be compiled for the various Ruby versions, these should nevertheless be shipped in the same binary package, also called ruby-foo. The naming convention can be of course adapted in the case of the packaging of utilities (chef, rails, redmine...). With the convention we used before, not only were we shipping distinct Ruby packages per interpreter version (i.e. libfoo-ruby1.8 and libfoo-ruby1.9.1) and needed to hold large-scale repackaging on ABI jumpis (as in the latest 1.9 → 1.9.1 change). With this new convention (and build system – read on for details) only one binary package will be built, and will carry all of the needed components, either in a common place or in the version-specific directories. Path of libraries ----------------- The libraries not bundled with the Ruby interpreters should be installed somewhere in /usr/lib/ruby/vendor_ruby directory, instead of /usr/lib/ruby/1.8 or /usr/lib/ruby/1.9.1. A Pure Ruby library working for all Ruby version would go in /usr/lib/ruby/vendor_ruby/ruby-foo/. Files specific to a version of the interpreter should go in /usr/lib/ruby/vendor_ruby/$RUBYVER (vendorlibdir). Code compiled specifically for the host architecture should go to /usr/lib/ruby/vendor_ruby/$RUBYVER/$ARCH (vendorarchdir) For the moment, MRI Ruby 1.8 and 1.9 can use the libraries installed in these directories. JRuby would need to have theses directories added to $LOAD_PATH and advertised by RbConfig (see #663342). Running test during build of packages ------------------------------------- A large number of Ruby libraries provide a test suite. It is recommended to run these tests during the construction of the package in order to check that the package will (at least partially) work with the interpreters and other libraries included in the distribution. A new packaging tool: gem2deb ----------------------------- If the library you are maintaining appears to be released as a gem, you can benefit from the "gem2deb" tool, which takes care of most of the points mentionned above in an automatised way. Instructions for the transition to gem2deb are available on the wiki page [2] of the team. 2: http://wiki.debian.org/Teams/Ruby/Packaging gem2deb builds binary packages which are amenable to all of the currently existing Ruby interpreters, and is future-proofed so that when a new one is included in Debian, all of our packages will gain support with just a rebuild. It also adds niceties such as proper Gem following via debian/watch or packaging with simple, current practices for debian/*. Please do consider repackaging using it! To conclude, we encourage Ruby Library maintainers to update their packages so that they follow the guidelines above. Everyone willing to team maintain their Ruby packages is of course welcome to join the Ruby Extras Packaging team (pkg-ruby-extras on alioth) and import their packages in the team repository. We would be happy to answer your questions and hear your comments on debian-ruby@lists.debian.org or on the #debian-ruby IRC channel. -------------------->8---------------------------------------
Attachment:
signature.asc
Description: Digital signature