[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Testing package installation, upgrading, and removal

Frank Lichtenheld and others have brought up the idea of automatically
testing installation, upgrading, and removal of packages. It struck me
that it should be pretty simple to implement at least basic versions of
this. The result: http://liw.iki.fi/liw/download/piuparts-0.4.tar.gz

I have attached the manual page.

The current version is quite simplistic. It may well be too simplistic
to work for more than in simple cases, but it's a start.

I'd be very curious to hear about suggestions for improvements.

piuparts(1)							   piuparts(1)

       piuparts  -  Debian  package installation, upgrade, and removal testing

       piuparts [-apvV] [-d distro] [-i filename] [-l logfile] [-m url] [pack-

       piuparts  tests that Debian packages can be installed and removed with-
       out ill effects. It is meant for people who create Debian  packages  to
       test them before they upload them to the Debian package archive.

       piuparts  creates  a chroot environment with a minimal Debian installa-
       tion, plus any packages that are needed for the test. It then  installs
       the packages, and removes and purges them, and checks that no files are
       left behind, and that no extra files are removed.

       The test consists of the following steps:

       1.     Create a chroot by running debootstrap, and configuring it suit-
	      ably.   Meta data (filenames and data returned by lstat) is cap-
	      tured and remembered for later.

       2.     Install the packages named on the command line. Technically this
	      works  by  doing	dpkg  -i  on  the  package files, then running
	      apt-get -yf, which installs also any missing dependencies.

       3.     Uninstall (first dpkg --remove, then dpkg --purge) the  packages
	      and what dependencies were added.

       4.     Compare the final state of the chroot with what was saved in the
	      first step. Any files that are missing,  modified,  or  new  are
	      reported. Modification is done only by comparing file meta data,
	      not actual file contents.

       If the package is known to apt-cache, piuparts  also  does  an  upgrade
       test,  where  it  first	installs  the  package	with apt-get, and then
       installs from the package files given on the command line, and  finally
       removes	and  purges  everything that got installed.  The assumption is
       that the version apt-get finds is older	than  the  package  file.  The
       upgrade test is not performed if -a is used.

       -a, --apt
	      The  package  arguments on the command line are to be treated as
	      package names and installed via apt-get instead of  being  names
	      of package files, to be installed via dpkg -i.

       -b tarball, --basetgz=tarball
	      Use  tarball  as	the contents of the initial chroot, instead of
	      building a new one with debootstrap.

       -d name, --distribution=name
	      Which Debian distribution to use: a code name (sarge, etch, sid)
	      or experimental. The default is sid (i.e, unstable).

       -i filename, --ignore=filename
	      Add  a filename to the list of filenames to be ignored when com-
	      paring changes before and after installation. By	default,  piu-
	      parts  ignores files that always change during a package instal-
	      lation and  uninstallation,  such  as  dpkg  status  files.  The
	      filename	should	be  relative  to the root of the chroot (e.g.,

       -l filename, --log-file=filename
	      Write log file to filename in addition to the standard output.

       -m url, --mirror=url
	      Which    Debian	 mirror    to	 use.	 The	default     is

       -p, --pbuilder
	      Use  /var/cache/pbuilder/base.tgz as the base tarball. This is a
	      shorthand so that you don't need to use -b for it.

       -s filename, --save=filename
	      Save the chroot, after it has been set up, into filename. It can
	      then be used with -b.

       -v, --verbose
	      Write also debugging log messages (used once) and really verbose
	      debugging log messages (used twice) to the standard  output.  If
	      there  are  additional  log  files, they always get all log mes-

       -V, --version
	      Write out the version number of the program.

       Assume that you have just built a new version of your  Debian  package,
       to  be  uploaded to Debian unstable. It is in ../foo_1.0-2_i386.deb and
       you would like to know whether it  installs  and  uninstalls  properly.
       Here's what you would do:

       piuparts ../foo_1.0-2_i386.deb


       Lars Wirzenius (liw@iki.fi).

				  2005-06-12			   piuparts(1)

Reply to: