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