[Piuparts-devel] support for complex upgrade scenarios

[Andreas Beckmann]

Hi,

something I'd like to test is the following scenario:

stable -> backports -> testing
(squeeze -> squeeze-bpo -> wheezy)

(and of course a plain install-purge test on the packages in backports, too)

For this we will need a more complex definition of packages sources
(with a minimal amount of redundancy) and interdependencies between tests.
And everything needs to be generic enough to not have debian specific
values hardcoded.

Given the following fragments:

[DEFAULT]
mirror = $MIRROR  # http://ftp.debian.org/debian
arch = amd64

[stable]
area = main
distro = stable

we can contruct several urls needed by different parts of the piuparts
suite:
* Packages file (master, report, slave)
$MIRROR/dists/stable/main/binary-amd64/Packages.bz2
* Sources file (report)
$MIRROR/dists/stable/main/source/Sources.bz2
* sources.list (piuparts)
deb $MIRROR stable main

testing is similar:

[testing]
area = main
distro = testing

backports is a partial repository, it needs a "base" repository (and
that needs a different mirror)

[backports]
mirror = $BPMIRROR
area = main
depends-distros = stable

With these setting we can (somehow) generate two sources.list lines (and
if it's too difficult to teach piuparts about this, we could generate
post_setup,pre_distupgrade custom scripts on the fly that create our
sources.list)

Furthermore we can discard packages from backports that are superseded
by packages in stable. (Yes, that's possible. Look at tor. Its more
common in stable-updates and stable-security due to point releases)

Something not yet covered are repositories that shall result in
  deb $MIRROR ./
lines (and respective Packages/Sources URLs)

Since this usage collides with our existing piuparts.conf, we need
either a second config file (e.g. distro.conf) or a section syntax that
does not collide (e.g. [distro:stable])

In piuparts.conf we could use this for just an install-purge test of the
packages in backports:

[backports]
distro = backports
depends-sections = stable

Since backports is a partial distribution, we need some place to look up
the state of "missing" packages, so let's take a sensible parent
(depends-sections)

In the piuparts.conf section for the actual upgrade test we could have

[stable2bpo2testing]
distro = backports
upgrade-test-distros = stable backports testing
depends-sections = stable2testing

where 'distro' specifies the [distro:...] section that generates the
list of packages to consider. The default should be the first entry in
upgrade-test-distros (but currently the last one is used)

Let's take some hypothetical packages with different versions:

pkg1  1.0  1.5~bpo  2.0
pkg2  None 1.5~bpo  2.0
pkg3  1.0  1.5~bpo  None
pkg4  1.0  None     2.0  (not in backports, not considered)

Then we could define the following upgrade scenarios that are to be
tested (in logfile syntax):

pkg1_1.0_1.5~bpo_2.0.log
pkg2_None_1.5~bpo_2.0.log
pkg1_1.0_1.5~bpo_None.log

To compute this, master needs to read all Packages files, not just the
"candidate" one.
If we manage to give this version list to piuparts, it can ensure that
exactly these versions (unless None) get installed and not any other one.

In order to make the whole scenario more complex, lets also consider
contrib and non-free (which are both partial distributions,
stable-updates, stable-security, experimental are as well), I'll switch
to [distro/area] section names for distro.conf (which will create more
subdirectory levels in master/,slave/,htdocs/, but this works nicely):

[stable/main]
area = main
distro = stable

[stable/contrib]
area = contrib
distro = stable
depends-distros = stable/main stable/non-free

[stable/non-free]
area = contrib
distro = stable
depends-distros = stable/main stable/contrib

nice: circular dependencies

similar for testing ...

[backports/main]
area = main
distro = backports
depends-distros = stable/main

[backports/contrib]
area = contrib
distro = backports
depends-distros = backports/main backports/non-free stable/contrib

[backports/non-free]
area = contrib
distro = backports
depends-distros = backports/main backports/contrib stable/non-free

the depends needs to be expanded recursively ... or we have to add
stable/main stable/contrib stable/non-free to backports/{contrib,non-free}

So we can define these tests in piuparts.conf:

[stable2bpo2testing/main]
distro = backports/main
upgrade-test-distros = stable/main backports/main testing/main

[stable2bpo2testing/contrib]
distro = backports/contrib
upgrade-test-distros = stable/contrib backports/contrib testing/contrib

[stable2bpo2testing/non-free]
distro = backports/contrib
upgrade-test-distros = stable/non-free backports/non-free testing/non-free

The last two entries would generate 6 sources.list entries
  deb $MIRROR stable main
  deb $MIRROR stable contrib
  deb $MIRROR stable non-free
  deb $BPMIRROR backports main
  deb $BPMIRROR backports contrib
  deb $BPMIRROR backports non-free

And we can even do this:

[stable2testing/main]
distro = stable/main  # default
upgrade-test-distros = stable/main testing/non-free

(upgrade test of packages moved from main to contrib or non-free; moving
between contrib and non-free or into main is uncritical)

And also this:

[distro:stable-custom/main]
mirror = $LOCALURL
distro = stable
area = main
depends-distros = stable/main

[stable-custom/main]
distro = stable-custom/main
depends-sections = stable/main

That was easy.

[stable-customized/main]
distro = stable/main
depends-sections = stable-custom

Let's override some packages from stable with our customized ones, if
that improves testing result, suggest the packages in stable-custom for
s-p-u ...


Oh, in addition to the sources.list we may have to set up
apt/preferences to fix some pinning (backports, experimental, ...)


What's working right now (in my instance, patches not yet polished for
publishing) is dependencies between piuparts.conf sections, that allows
install-purge tests of partial distributions (-security, -backports,
-updates, experimental as well as contrib, non-free and combinations)
sid2experimental is working as well, but all these need a lot of custom
script hacks at the moment.

To continue development, we need

* to decide how we want the config layout (distro.conf or [distro:foo]
or ...)
* implement these for distro configuration
* implement generating sources.list for complex scenarios
* ...
* implement generating version sequences (may contain None) to exactly
describe the upgrade scenarios we want to test



Andreas