[Piuparts-devel] RFC: preview/target-repo

[Andreas Beckmann]

Andreas Beckmann (1):
      add --target-repo option

This is the first part of a longer series, and here I primarily look for
a "good name" of this new feature.

For testing more complex install/upgrade scenarios (i.e. something that
involves dependencies that are not yet in the archive) I propose the
following:

* add a new option "--target-repo" (better name suggestions welcome)
that accepts a deb line like
  deb URL distro component...
or
  deb file:///bind/mount ./
that points to a (local) repository that contains all the packages
needed to satisfy dependencies during the test (and perhaps some more
packages that are not really needed) - usually everything built from the
source package of some target package to be tested, but maybe some more
source package are involved in some bigger change so the packages can be
provided there, too

* an alternative would be to provide all .debs needed on the command
line (and order them manually properly), but
  - that does not allow for separating package-under-test and
    dependencies
  - does not check apt dependency resolution

* another alternative would be to test one (or more) .changes files with
piuparts - but we usually find more errors by doing single-package tests
(and the .deb order extracted from the .changes is always¹ "wrong",
causing dpkg dependency errors where apt would reorder the packages
properly)
¹ cf. Murphys Law

* that repository will be enabled only for
  - the install-purge test
  - the upgrade part of the install-upgrade test
  - the last step of the distupgrade test

* for the distupgrade test there will be tow options to test
  - does an dist-upgrade from testing to sid to the new packages work?
    (aka $package-users running the current sid version)
    (or: does it cleanup some mess caused by the current package in sid)
  - does an dist-upgrade from testing to the new package work?
    (aka $package-users running the current testing version)
(where sid and testing are not hardcoded, of course, so you can build
arbitrary paths)

* The packages to be tested can be passed as .debs (but the .debs will
only be used to extract package name and version, installation will take
the matching package from the provided repo - if the package is missing
there, this is an error) or as (optionally version-qualified) names with
the --apt option.

The goal is to finally allow maintainers to test their packages with
piuparts including weird upgrade scenarios *before* uploading them to
the archive.

So how would you call such a repository? And the option to specify it?

Would it be useful to allow multiple of these option, each adding a
separate deb-line?

See also #676694
This would in some way also fix #588041 by providing a much more
powerful way to avoid this problem. (I tested creating a file:///
repository on the fly, but that only works if all the packages needed
are supplied on the command line - which is a very special case only)


Andreas