svn-buildpackage - Improvements

The idea is to majorly improve svn-buildpackage and release 0.7. Therefor here we are collecting thoughts about improvement ideas and try to discuss them. Still, at the moment it's just a poor list of ideas!

Getting some OOP

Think of a class (SvnBp::Repository). It's generally a wrapper around SVN::Client but with detailed knowledge of what is needed in the build process. It "knows" about layouts supported by svn-bp and is able to handle standard subversion commands (via SVN::Client). Also it's now easier to add new layout types if needed because they are defined in seperate modules.

A class will also be developed to handle unpacking and building packages. It's supposed to make use of dpkg-source, devscripts if needed, and maybe even of classes out of dpkg-dev (e.g. to parse the dsc file). If necessary (I don't hope so) subclasses for different source package formats can then also be developed.




I hope to get some "running" code in a few days. Then I'll be uploading it to the svn-buildpackage repository (collab-maint) in a 0.7 branch. (I'll send a mail to -devel for comments then.)

ini style configuration file

My idea would be to get rid of old ballast. We need to figure out what data can/may be stored in subversion properties and what data is to be stored in config files. That may overlap of course but it needs to be properly thought about AND be well documented. I think that since we probably break current configs we should change to a perl config class to parse the config files. It would make things easier and more flexible.

Where to store what...

My first intention is to make svn-bp guess less about repository structure and similar. I want layout information to be stored as a svn-property (svn-bp:layout = $int). If the repo stores tarballs and/or upstream sources there should be some information about it, too (Looking up for upstream sources is easy when layout is defined but guessing around in a repo for some sort of a tarball or origs dir is ugly).

Regex in a conf file

Thinking about e.g. the TeX maintainers I can see a win in having grouped config vars where the group is a regex. For instance:

[general] ## these are my personal settings for new packages
checkout = 1
layout = 2

[(tex-.*|texlive-.*|tetex-.*)] ## perl regex for all tex related packages
layout = 1

add-tar = 1

I know that means breaking an existing conf file but it's for good, isn't it?


Build from branches and all about it

Getting rid of upstream/current

To be able to build from branches one must be able to build with different upstream versions. This would be impossible sind svn-bp always take upstream/current into account. With ?SvnBp::Repository we would be able to easily handle branch URLs which is good for building from branches but upstream still needs a solution. An idea is to store a subversion property in trunk and every branch which holds the upstream version. svn-bp would then read out something like svn-bp:upstream and look for that version in the upstream directory/URL. svn-bp would be able to build against different upstream versions.

More advantages

Also, if we go that way it's easier to work with svn-bp repositories. Without dealing with the layout (without even knowing the layout of the repo) you can provide a switch, tag and copy command, e.g.

svn-buildpackage copy trunk branches/lenny

svn-bp then looks up the layout type, creates proper URLs and uses SVN::Client to perform the action.

Make more use of devscripts

Current svn-bp sometimes does things that are already implemented in devscripts. svn-bp should make use of those scripts. Maybe svn-bp can even be improved by that. I'd imagine svn-upgrade to upgrade to the new upstream version automatically downloaded by uscan.

Implementing "modes" instead of having different scripts

This is truely the mose invasive proposal. The idea is to have one script that knows about different modes instead of having (to maintain) three or even more scripts working on similar stuff. That would give the simple possibility to add more modes in future version. So, in easy words:

To not break everything I'd say calling svn-bp without any mode means to build; also there should be symlinks from svn-inject and svn-upgrade that automatically invoke the right mode. Something like "svn-buildpackage --svn-tag" in current svn-bp would then be equal to "svn-buildpackage build && svn-buildpackage tag" (or of course "svn-buildpackage buildandtag" which can easily provided).

Another thing I would like about this is having conforming command line options for all modes.

Source Format 3.0

We can deal with that in the dpkg-source is supposed to get a --skip-debianization option which makes it fairly easy to get upstream sources of a package without dealing with different source package formats.