Re: ruby-pkg-tools proposal
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 <zoso@foton.es> - http://www.foton.es
EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es
Reply to: