Hi Lucas, I totally support your idea. Also i have some suggestion.
1) I have raised ITP for dh_make_ruby[1] long back to prepare this, but somehow it was available with other upstream, I haven't looked existing one so still not clear about this that do we need to use existing one or need to prepare from scratch. 2) I have already created a script repack.sh to convert gemtotar format. we can use this (if it is not buggy). its available in svn[2]. let me know your input. [1]http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=436537 [2] http://svn.debian.org/wsvn/pkg-ruby-extras/trunk/libdataobjects-ruby/debian/repack.sh Thanks Deepak On Thu, Apr 22, 2010 at 1:37 AM, Lucas Nussbaum <lu...@lucas-nussbaum.net>wrote: > [ Please continue the discussion on debian-ruby@ ] > > Hi, > > I'd like to restart a discussion on a set of changes in ruby packaging. > The goals are: > - to find a way to deal with the popularity of rubygems. > - to simplify ruby packaging, so we can keep up with the number of > popular/useful gems > - to be able to support several ruby interpreters at the same time, > preparing the switch to 1.9.X > All those changes are for squeeze+1, but we can start discussing them > now. > > I'd like to propose the following actions. > > 0) We try to provide as much support as possible for all ruby interpreters > (well, at least 1.8 and 1.9.1, but maybe also jruby). However, we decide > on a default version (1.8 currently) that all libraries must support. > > 1) We base our packaging on rubygems. This doesn't mean that we package > gems > directly. But we take upstream gems, convert them to .orig.tar.gz (easy), > and > then apply our Debian-specific tools. That allows use to keep the > maximum flexibility of what we can do with the source (patching, etc). > > 2) Instead of installing to /usr/lib/ruby/1.{8,9.1}, we install to: > /usr/lib/ruby/vendor_ruby/ <= libraries that support all versions > of the interpreter > /usr/lib/ruby/vendor_ruby/1.8 <= libraries that only support 1.8 > /usr/lib/ruby/vendor_ruby/1.9.1 <= libraries that only support 1.9.1 > That allows to make a better difference between the stdlib and the > third-party libraries. > > 3) Instead of providing several libfoo-ruby1.{8,9.1} packages, we > provide only one when it is possible (pure ruby packages), named > libfoo-ruby. > When this is not possible (case of packages that contain native > extensions), > we continue to provide several binary packages libfoo-ruby1{8,9.1}. > > 4) When packages provide executable scripts, we either : > - provide them for the various Ruby implementations that we support, > using 1.8, 1.9.1 suffixes. (case for development tools) > - or provide them only for the default version of ruby (case of normal > applications) > > 5) Regarding test suites, we should really try to execute them during the > build (for every ruby implementation), as this will allow to detect > regressions. > > TODO items, provided we agree on the above: > > - determine how to deal with Depends, especially in the case of > a pure-ruby library requiring a native extension. > > - decide if we want to keep our current cdbs-based packaging system, or > if we want to switch to dh. That would be a nice opportunity. > We might want to really fork setup.rb, too. > > - write a set of scripts to package from gems, including: > + gem2tgz - convert gem to tgz, saving the gem metadata somewhere > + dh_make_ruby - prepare a source package, making use of the gem metadata > + script to watch gems on rubygems.org (for debian/watch) > + various QA scripts, including one to grep for "require 'rubygems'" > > Some data: > I've looked at the top 200 gems on rubygems.org. > 194 of them provide a lib/ directory, so they probably support > setup.rb-based > installation. Of the remaining 6 packages, only 2 don't provide ext/, and > 1 has a good reason for that. > 55 use "require 'rubygems'" in lib/ somewhere. > 112 have a test/ directory, 49 have a spec/ directory. > -- > | Lucas Nussbaum > | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | > | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | > > > -- > To UNSUBSCRIBE, email to debian-ruby-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: http://lists.debian.org/20100421200717.ga32...@xanadu.blop.info > > -- Deepak Tripathi E3 71V3 8Y C063 (We Live By Code) http://deepaktripathi.blogspot.com