SVN-BUILDPACKAGE(1)

πŸ“¦
version 0.8.10 Β· 2 versions
  • 0.8.10 Β· debian bookworm, debian trixie, ubuntu noble, ubuntu resolute, ubuntu stonking (latest)
  • 0.8.7 Β· ubuntu jammy
, in debian bookworm, debian trixie, ubuntu noble, ubuntu resolute, ubuntu stonking

SVN-BUILDPACKAGE πŸ’…βœ¨

svn-buildpackage β€” the Command reference page, bestie. Manual section 1. Let's get into it 🫢


🌸 NAME 🌸

svn-buildpackage β€” build Debian packages from an SVN repository πŸŽ€


✨ SYNOPSIS ✨

svn-buildpackage [[ OPTIONS... ] [ OPTIONS for dpkg-buildpackage ]]

πŸ¦‹ DESCRIPTION πŸ¦‹

So basically: this thing builds a Debian package straight out of a Subversion repository. No cap. Your source code repo has to be in the format that svn-inject creates, and you must run this script from the working directory, aka trunk/package. Don't be out here running it from anywhere else πŸ™ˆ

By default, the working directory is what gets used as the main source directory β€” that's assuming the whole upstream source is chilling in the repository. Simple. Clean. Iconic.

But there's another way, and it's called "merge mode". With this method, only the debian directory (and maybe a few other modified files) live in the repo. At build time, the contents of the svn trunk get copied onto the extracted tarball contents, and yes, they can overwrite parts of it. To pick this working model, you set the svn property mergeWithUpstream on the debian directory:

$ svn propset mergeWithUpstream 1 debian

mergeWithUpstream requires that the build system can actually prepare a tarball β€” typically using make dist and autotools. All upstream packages will have some form of tarball creation support, and native packages that use autotools or that have internal tarball support can use mergeWithUpstream to handle generated files that are needed to build the package but aren't present in SVN. See the HOWTO guide for examples of how this can be done. πŸ‘‘

Native packages that don't use autotools and don't have internal tarball support can still add generated files to the source package tarball using the useNativeDist make target in the top level Makefile. This custom target must be idempotent and only modify / generate the desired files using only the exported SVN source and build dependencies. To let svn-buildpackage use a make native-dist target in your top level Makefile, set the useNativeDist property on the ./debian/ directory:

$ svn propset useNativeDist 1 debian

The default behaviour of svn-buildpackage is as follows:

  • Check the working directory, complain on uncommited files (also see --svn-ignore-new) πŸ‘€
  • Copy the orig tarball to the build area if necessary (also see --svn-no-links)
  • Extract the tarball (in merge mode) or export the svn work directory to the build directory (also see below and --svn-no-links)
  • Build with dpkg-buildpackage (also see --svn-builder, --svn-lintian, etc.)
  • Create a changelog entry for the future version

πŸ’… OPTIONS πŸ’…

svn-buildpackage accepts the following options on the command-line:

  • --svn-builder=COMMAND β€” Specifies an alternative build command instead of dpkg-buildpackage, e.g. debuild, pdebuild, etc. Every parameter that svn-buildpackage doesn't know (--svn-*) is passed to COMMAND. There is no difference between the command line and config file parameters. They are used at the same time.
⚠️ WARNING: shell quotation rules do not completely apply here, better use wrappers for complex constructs. Using this option may break --svn-lintian and --svn-move functionality. Some functions may be disabled when a custom build command is used because the output file location is not predictable. 😭

Default: use dpkg-buildpackage.

  • --svn-ignore-new | --svn-ignore β€” Don't stop on svn conflicts or new/changed files. To set this behaviour for single files, set the deb:ignoreM property to 1 on them. Also see documentation of the svn:ignore property in the SVN book.

Default: Stop on conflicts or new/changed files.

  • --svn-dont-clean β€” Don't run debian/rules clean.

Default: clean first

  • --svn-no-links β€” Don't use file links but try to export or do hard copies of the working directory. This is useful if your package fails to build because some files, empty directories, broken links, ... cannot be transported with in the default link-copy mode. 🫢

Default: use links where possible.

  • --svn-dont-purge β€” Don't remove the build directory when the build is done.

Default: remove after successful build.

  • --svn-reuse β€” If possible, reuse an existing build directory in subsequent builds. The build directory is not purged after the build, it is not renamed when a build starts and the files are just copied over into it. Useful in mergeWithUpstream mode with large packages. πŸ‘‘

Default: build directory is removed.

  • --svn-rm-prev-dir β€” If a previous build directory is found, remove it before building instead of renaming it. If --svn-reuse is also given in the same line, the reuse behaviour occurs.

Default: rename old directories with a 'obsolete' suffix.

  • --svn-export β€” Just export the working directory and do necessary code merge operations, then exit.

Default: Off.

  • --svn-tag β€” Final build: Tag, export, build cleanly & make new changelog entry. ✨

Default: Off.

  • --svn-tag-only | --svn-only-tag β€” Don't build the package, do only the tag copy.

Default: Off.

  • --svn-retag β€” If an existing target directory has been found while trying to create the tag copy, remove the target directory first.

Default: Off.

  • --svn-noautodch β€” No new Debian changelog entry is added automatically.

Default: A new UNRELEASED changelog entry is set via dch.

  • --svn-lintian β€” Run lintian on the resulting changes file when done.

Default: Off.

  • --svn-move β€” When done, move the created files (as listed in .changes) to the parent directory, relative to the one where svn-buildpackage was started.

Default: Off.

  • --svn-move-to=... β€” Specifies the target directory to which to move the generated files.

Default: Off. (Files are left where the build command puts them.)

  • --svn-pkg=packagename β€” Overrides the detected package name. Use with caution since it could be set too late during the processing (eg. still have the old value when expanding shell variables). 😬

Default: Off.

  • --svn-arch=ARCH β€” Allows specifying the build architecture (e.g. i386 build on an amd64 machine).

Default: Off.

  • --svn-override=var=value,anothervar=value β€” Overrides any config variable that has been autodetected or found in .svn/deb-layout.

Default: Off.

  • --svn-prebuild | --svn-postbuild | --svn-pretag | --svn-posttag β€” Commands (hooks) to be executed before/after the build/tag command invocations, e.g. to download the orig tarballs from the archive. Shell code can be emdded here though it is not recommended. Various helping variables are available in the environment, see ENVIRONMENT VARIABLES below for detailed explanation.

Please note that the prebuild and postbuild hooks replace the normal prebuild and postbuild actions of svn-buildpackage. For prebuild, this means that the build dependencies will not be checked. For postbuild, this means that the resulting files won't be moved, and lintian will not be run. πŸ’€

Defaults: Off.

  • --svn-noninteractive β€” With this parameter svn-buildpackage will not interact with the user.

Default: Off.

  • --svn-savecfg β€” By default, svn-buildpackage used to create .svn/deb-layout on every invocation. Since version 0.6.22 this behaviour is deprecated.

With this parameter svn-buildpackage will (partly) replicate the old behaviour. In contrast to the deprecated behaviour, the .svn/deb-layout is regarded as a local override; the old behaviour simply ignored any versioned layout information if it found .svn/deb-layout.

This option was provided since it can be useful when creating a local override file.

Default: Off.

  • --svn-download-orig β€” This option makes svn-buildpackage try to download the upstream tarball using apt and uscan. 🌈

Default: Off.

  • --svn-verbose β€” More verbose program output. πŸ—£οΈ

Default: Off.

  • -h | --help β€” Show the help message.

πŸŽ€ EXAMPLES πŸŽ€

For more detailed information on how to use svn-buildpackage, see the HOWTO http://svn-bp.alioth.debian.org/[1]. πŸ”₯

To start working with an existing native Debian package from a *.dsc file, import it into the repository with command:

svn-inject package_0.1.dsc svn://host/debian/devel/packages

To start working with an existing upstream package in Debian from a *.dsc file, import it into the repository with command:

svn-inject -o package_0.1-2.dsc svn://host/debian/devel/packages

Before building an upstream package, ensure the original source is available, e.g. if uscan is working:

svn mkdir ../tarballs
svn propset svn:ignore "*" ../tarballs
uscan --force-download --destdir ../tarballs

To test building the package from Subversion repository, use the command below. Refer to dpkg-buildpackage(1) manual page for the -us etc. options:

svn-buildpackage --svn-lintian -us -uc -rfakeroot

To check that the package builds in a clean state, test it with pbuilder(1):

svn mkdir ../build-area  # To store results
svn propset svn:ignore "*" ../build-area
svn-buildpackage --svn-ignore-new --svn-builder=pdebuild

When a new upstream release becomes available, commit all changes and have the working tree in clean state. Then use svn-upgrade(1) to import the new release:

svn status   # Check that there are no uncommited changes
svn-upgrade --verbose ../package-2.0.tar.gz

🧚 CONFIGURATION FILE 🧚

svn-buildpackage's behaviour can be modified using the file ~/.svn-buildpackage.conf. Additional parts can be added in each package working directory using the file .svn/svn-buildpackage.conf. It is essentially a list of the long command line options (without leading minus signs), one argument per line (without quotes surrounding multi-word arguments). The variables are expanded with the system shell if shell variables are found there. Avoid the ~ sign because of unreliable expansion: it is better to use $HOME instead. Example:

svn-builder=debuild -EPATH
svn-no-links
svn-override=origDir=$HOME/debian/upstream/$PACKAGE
# svn-ignore-new
#svn-lintian

(part 1 of 2 β€” more coming, don't go anywhere bestie)

πŸ“ DIRECTORY LAYOUT HANDLING πŸ—‚οΈ

okay so by default, svn-buildpackage is out here looking for a config file that declares your paths and urls, and that file lives at .svn/deb-layout. πŸ’…

the values in there? totally overridable with the --svn-override option (peep the section above bestie, it's all there). and if no config file shows up at all? no stress β€” the settings get autodetected following the usual assumptions about local directories and repository layout. ✨

also!! there's a custom file, debian/svn-deblayout, and its contents get imported during the initial configuration. package maintainers can stash this file in the repository so that new svn-buildpackage users get the correct defaults handed to them. 🫢 the format is literally the same as the one in .svn/deb-layout, no cap.

as an alternative to the debian/svn-deblayout file, maintainers can set Subversion properties for the debian/ directory. any properties of debian/ whose name has the form svn-bp:PROP become the source of a PROP setting, and its value is whatever the first line of the property value says. if a full svn URL isn't given, the repository root gets prepended to that value. 🌸


🌈 ENVIRONMENT VARIABLES ✨

these environment variables are exported by svn-buildpackage and can be used in hook commands or in the package build system. the way that's so handy for real. πŸ’–

  • PACKAGE, package β€” the source package name.
  • SVN_BUILDPACKAGE β€” the version of svn-buildpackage.
  • TAG_VERSION, debian_version β€” the complete Debian version string, also used for the tag copy.
  • non_epoch_version β€” same as debian_version but with any epoch strings stripped out.
  • upstream_version β€” same as debian_version but without the Debian extensions.
  • guess_loc β€” the guessed upstream source package name in the pool, something like libm/libmeta-html-perl_3.2.1.0.orig.tar.gz.
  • DIFFSRC β€” (experimental πŸ‘€) shows the location of the generated diff file.

🧚 all the layout properties ✨

all the layout properties get exported to the environment too, bestie. the following ones actually mean something to svn-buildpackage:

  • buildArea β€” the location of the build area directory.
  • trunkUrl β€” the URL of the trunk directory for the current package.
  • tagsUrl β€” the URL of the tags base directory for the current package.
  • origDir β€” the local directory where the orig tarball should be located.
  • origUrl β€” the URL from where the orig tarball for the current package can be pulled from.

πŸ’œ variables that svn-buildpackage understands πŸ”₯

these ones are read by svn-buildpackage itself:

  • FORCETAG β€” ignore the signs of an incomplete changelog and tag the repository anyway. living dangerously, love that for you 😭
  • FORCEEXPORT β€” export upstream source from the repository even if the mergeWithUpstream property is set.
  • DEBIAN_FRONTEND β€” if DEBIAN_FRONTEND is set to 'noninteractive', then --svn-noninteractive is called silently.

πŸŽ€ RECOMMENDATIONS πŸ’…

use shell aliases. periodt. here are some examples for Bash:

alias svn-b="svn-buildpackage -us -uc -rfakeroot --svn-ignore"
alias svn-br="svn-b --svn-dont-purge --svn-reuse"
alias svn-bt="svn-buildpackage --svn-tag -rfakeroot"

and those commands have their own respective meanings, queen:

  • build regardless of new or changed files;
  • build regardless of new or changed files and reuse the build directory;
  • build (for upload) and tag. πŸ‘‘

SSH is the easiest way to access remote repositories, although it usually means entering a password way more frequently with svn-buildpackage. 😭 workarounds include using an ssh key without a passphrase (although that's insecure and still relatively slow, so be careful bestie), or the SSH connection caching feature present in recent versions of SSH. for the details, see the svn-buildpackage manual.

another way to get a remote link is using the Subversion DAV module (with SSL and Apache user authentication) β€” see the svn-buildpackage HOWTO manual for the deets. 🌸


πŸ‘€ SEE ALSO 🌈

  • /usr/share/doc/svn-buildpackage/() β€” the svn-buildpackage HOWTO manual
  • svn-inject(1) β€” puts a Debian source package into a Subversion repository
  • svn-upgrade(1) β€” upgrade source package from a new upstream revision
  • svn(1) β€” Subversion command line client tool
  • dpkg-buildpackage(1) β€” Debian source package tools
  • lintian(1) β€” Debian package checker

πŸ‘‘ AUTHORS 🫢

  • Eduard Bloch β€” this manual page was written by Eduard Bloch in roff.
  • Goneri Le Bouder β€” converted manpages to SGML.
  • Neil Williams β€” converted manpages to DocBook XML and current Debian maintainer.

Copyright Β© 2009 Eduard Bloch


πŸ“ NOTES ⭐

  1. http://svn-bp.alioth.debian.org/ β€” http://svn-bp.alioth.debian.org/

and that's the whole page bestie, we ate and left absolutely no crumbs πŸ’…βœ¨ this one's from Release: 0.8.2, dated May 2009, and it's the SVN-BUILDPACKAGE(1) page β€” iconic, historic, we love her πŸŽ€πŸ¦‹