Hi all, I've been thinking about this for some time, but have been unable to _act_ on it. I recently joined the pkg-ruby-extras Alioth team [1], which does +- the same we do for Perl, but (duh) for Ruby. I have noticed quite a few things I want to copy to our work process, as they seem to be just the right way to work. I've left this mail unwritten until I got familiar with their ways, but it might be too much, and I want to get this out as soon as possible. Of course, all the changes I'm proposing will have to wait until Etch is released. 1. There is a special package called ruby-pkg-tools, which includes metainformation and some handy scripts for building the rest of the group's packages. I'll talk about some of its files shortly. 2. ruby-pkg-tools includes a list of the group members [2], /usr/share/ruby-pkg-tools/pkg-ruby-extras.team - Why? Because, instead of having the mess we currently have, where each of us adds his email to the Uploaders: field of each package's debian/control, debian/control is built with the name of each of the maintainers. 3. CDBS classes [3]. I'm still uncertain about this one, but all in all, it makes sense. Most of our makefiles are just the same over and over. When we have done changes to our build process (i.e. replacing the -$(MAKE) distlean with the conditional variant), it has been quite an invasive and error-prone approach. Too many ways of doing very similar things (yes, like the Perl motto - but still, I don't see much benefit with the current situation). Of course, you are all familiar with my error-fixing extra commits (BTW, just not to break tradition, it took me _six_ commits to get my name added to pkg-ruby-extras.team ;-) ). I do not like CDBS too much, but it is greatly because I have not used it much, and it's harder to debug something you are not familiar with. Probably we should build a couple of CDBS classes for all of our packages, and do away with our individual makefiles. 4. A simple, automatic way to get the upstream sources [4]. You don't have to manually fiddle with creating build-area, putting and renaming the orig.tar.gz there. It's automatable. And, hey - If debian/watch has the information, if uscan can check if there are new versions, why must we do it manually? Well, there must be a reason not to rely on debian/watch for everything - They have a YAML file in their SVN describing where are the sources for each package. What do you say? I think the four points are important. Of course, it's too invasive for before Etch, but I do hope to start working on this as soon as the release hits the shelves. Greetings, [1] http://pkg-ruby-extras.alioth.debian.org/ [2] http://pkg-ruby-extras.alioth.debian.org/ruby-pkg-tools/uploaders.html [3] http://pkg-ruby-extras.alioth.debian.org/ruby-pkg-tools/cdbs.html [4] http://pkg-ruby-extras.alioth.debian.org/ruby-pkg-tools/sources.html -- Gunnar Wolf - gwolf@gwolf.org - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Attachment:
signature.asc
Description: Digital signature