= 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 Repository.pm 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 DPack.pm 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. === Advantages === * No need for system calls on subversion: system('svn add endless_line_of_files'); * Just one authorization needed during entire build process * Easy way to handle branches in different layouts === Disadvantages === * At least that means major rewrites of *some* code === Implementation === 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 [(lib.*-perl)] add-tar = 1 }}} I know that means breaking an existing conf file but it's for good, isn't it? === Discussion === * How about storing the layout information in the properties of the base URL instead of relying on local configuration? The person committing the package has that info when committing and it could be added to the base URI of the dir, where later, other clients would read it and build on that. If you want teams to work with svn-bp, you have to make sure everybody has their job eased up. EddyP 2009-05-15. * Fair enough. When I wrote the regex part I was thinking about new packages. I would also make more use of svn properties and those should overwrite configurations in conf files. jhr 2009-05-15. == 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: * svn-buildpackage inject * svn-buildpackage upgrade * svn-buildpackage build * svn-buildpackage tag * svn-buildpackage switch * svn-buildpackage checkout * svn-buildpackage do 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 DPack.pm. 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.