Re: ruby-pkg-tools proposal
On Sat, Aug 27, 2005 at 11:00:48PM +0100, Esteban Manchado Velázquez wrote:
> 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)?
No, the policy has a FIXME for that at the moment. For RDoc HTML I
would say /usr/share/doc/<package>/rdoc, and the RI data goes to
/usr/share/ri/<version>/system. This would mean that the RI data has to
be in the -ruby1.8 package, which is still kind of strange since the
source doesn't change depending on the version so why should the
documentation.
Package-wise it is also not very clear, the -ruby and -ruby1.8 both seem
bad candidates, but a -ruby-doc package is sometimes quite overkill.
> > * /usr/bin/dh_ruby: script to determine dependencies, ala
> > dh_python/dh_perl.
>
> I guess this should be pretty easy to do.
But not trivial :)
> > * 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...
Ah, but that is a entirely different story. OK, I don't know how
generic it is now, I see some dirs in /usr/share/debhelper/dh_make but
are they hardcoded then? If so, a generic system would be a nice idea.
> > * 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?
Well, we expect to have at least one Debian Ruby Maintainer team, so the
list of uploaders could be in a makefile for use by CDBS. If you join
the team and get Subversion access, you can put yourself in there and
all packages will get you in the Uploaders.
See for example in gnome-pkg-tools:
/usr/share/gnome-pkg-tools/pkg-gnome.team
/usr/share/gnome-pkg-tools/1/rules/uploaders.mk
> > * /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...
Well, it seems to have been written for/before the 1.6 -> 1.8 transition
and still needs some updating but also filling in of some blank parts.
You can see it at: http://pkg-ruby.alioth.debian.org/ruby-policy.html/index.html
Possibly soon I and others will throw some new drafts/proposals at you here
on this list. :) Note also that there are a lot of policy violations
out there, so converging on it should be a joint effort.
> 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?
No. Some discussion was planned for the BOF at Debconf though, although now
I begin to suspect it didn't happen. During the past months I have
encountered some issues and got some idea and I've written them down.
I will mail them to the list for discussion purposes soon, then.
> Perhaps we could setup a Wiki somewhere (e.g., in the ruby-pkg-tools
> Alioth project) to coordinate this.
For now there is only a ruby-pkg-extras project, but the ruby-pkg
project currently hosts the policy. So it would be confusing to do that
in the ruby-pkg-extras now. I do not know if it's necessary to create a
ruby-pkg-tools project as well. For me, there are two domains in Ruby:
the one of the core (interpreter, stdlib) and one for all libraries and
apps. Right now those map to pkg-ruby and pkg-ruby-extra respectively
and ruby-pkg-tools definitely falls in the second domain.
> > 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 ;-)
Ok, good. I'll start working on something then.
Paul
--
Student @ Eindhoven | email: paulvt@debian.org
University of Technology, The Netherlands | JID: paul@luon.net
>>> Using the Power of Debian GNU/Linux <<< | GnuPG key ID: 0x50064181
Reply to: