On Fri, Aug 26, 2005 at 05:33:57PM +0200, Paul van Tilburg wrote: > Hi all, > > There has been a discussion here about where I for example could stuff > my CDBS class. With Esteban also working on one, we have talked and > decided to merge them and join our efforts. I have also talked with > Jeff Bailey (CDBS maintainer) and he's not to happy about joining it > (yet) but is interested in a CDBS 2 class. So I thought, why not follow > in GNOME's footsteps (gnome-pkg-tools) and create a ruby-pkg-tools > package. > > What should/can it contain? > > * /usr/share/cdbs/1/class/ruby-setup.mk: the CDBSv1 class to easily > handle the install part of a Ruby Package debianization.
I think this is very very important. Right now, packaging Ruby libs is error-prone, unnecessarily difficult, and messy. All the redundant code should be refactored to a CDBS class, for our own mental peace sake ;-) > * /usr/bin/dh_rdoc: script handling HTML & Ri documentation generation, > it can determine whether that is already available upstream or > generate it itself and install it to the policy-wise right place. Great. Has it been decided _where_ to put that documentation (both directory-wise and package-wise)? > * /usr/bin/dh_ruby: script to determine dependencies, ala > dh_python/dh_perl. I guess this should be pretty easy to do. > * some stuff for dh-make-ruby, or maybe an extension for dh_make (don't > know if this is possible). I was thinking about doing some _generic_ dh-make, to replace dh-make, dh-make-perl, etc. By means of templates we could use one "framework" (we can call it dh-make-ng) for all package types... I have some ideas about this, and can expand if someone is interested... > * some make files usable to define teams in, for example the team > preparing libruby-extras. These can be included to create debian/control > from debian/control.in. I'm not sure what you mean here: do you mean something like a simple macro system, to generate debian/control from a debian/control.in template and some bits/variables, or another thing? > * /usr/share/doc/ruby-pkg-tools/ruby-policy.html: a HTML version of Ruby's > policy. What's the current status for the Ruby policy? I don't know how much time/effort has been put into it, and I don't know either how "complete" it is... For example, a couple of days ago, when we talked, he suggested changing/adding some Ruby directories to the default $LOAD_PATH, to conform to the FHS. By adding another version-independent directory to $LOAD_PATH, we could also get rid of version-dependent deb packages when it's not necessary. Naturally, this would heavily influence Ruby Policy. Has been any discussion about this taken place? Perhaps we could setup a Wiki somewhere (e.g., in the ruby-pkg-tools Alioth project) to coordinate this. > What is it for? > > With the dh_* tools following the Debian policy, we can let the stuff of > this package deal with the Debian/Ruby policy (more on that later this > week). A Ruby lib package would just have build-depends on ruby-pkg-tools > and optionally the binary headers/libs it needs to have for building the > extensions and it's done. Easy come, easy go :) > > I am ready/willing to create this package. OK, this is partly because I > need that class, hehe, but also consider this to be the first step for > the team. So what do you guys think? Of course, I think it's a great idea ;-) Regards, -- Esteban Manchado Velázquez <[EMAIL PROTECTED]> - http://www.foton.es EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
