New Target-Depends control field?

[Colin Watson <cjwatson@debian.org>]

In order to support sarge in d-i, as well as various fairly trivial
pieces of compatibility code such as in base-installer, we need to
ensure that we aren't relying on the ability to run code in /target
which was added after sarge. We've got a rough idea at the moment of
where the main problems are here (basically, pkgsel won't work with
sarge's debconf and tasksel), but it's entirely possible that e.g. some
bootloader installer has been or will be made to depend on having a
newer version of its associated bootloader available in /target, and we
have no machine-readable way to track that at the moment.

I was thinking last night of a couple of possible changes which might
help matters here:

  * Versioned apt-install

    Make apt-install take (quoted) arguments of the form 'debconf (>=
    1.4.66)' or 'grub (>> 0.97)' (usual Depends syntax, only >= and >>
    relations supported, no |-ed alternatives or funny stuff like that).
    These will cause it to fail (exiting non-zero) if it can't satisfy
    the requested relation.

  * Introduce Target-Depends binary control field

    This would be a comma(+whitespace)-separated list of dependencies
    that you can give to apt-install, pretty much like a normal Depends
    field only with more restricted syntax.

    The semantics are that when configuring a udeb before the base
    system has been installed, main-menu will queue the requested
    packages for installation in /target using apt-install; and when
    configuring a udeb after the base system has been installed,
    main-menu will try to install the requested packages in /target just
    before running the udeb's postinst. If the latter fails, it may
    display an error, or may silently decide that the udeb can't be
    configured and configure something else instead (perhaps it might
    configure nobootloader instead of a bootloader installer); I'm not
    sure which would be best.

I think the former should be relatively uncontroversial, and would at
least allow us to grep through d-i for versioned apt-install commands.
The latter is a rather bigger change. I think the benefits are that it
would potentially let us do things like not let udebs into testing
without the debs they rely on or make sure debian-cd puts all the debs
we need on CD images; it would let us get rid of lots of duplicated code
and translated templates that are just doing apt-install and reporting
failures; and it would let us look through the d-i Packages file for
issues affecting the ability to install sarge. Of course, we wouldn't be
able to get rid of all apt-install commands since some are optional.

Does anyone else think this would be useful? If so, I can put some
effort into implementing it.

-- 
Colin Watson                                       [cjwatson@debian.org]