This is good stuff[1].
Colin Watson wrote:
> * 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.
I like this idea.
> * 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.
I like the idea of such a field from a pure metadata perspective. It's
annoying to have to grep the tree for apt-install calls; in some cases
you have to read the code ("apt-install $myvar"), and as noted having it
available as metadata would allow for further use of the data by
britney, debian-cd, etc.
The metadata does need to have an effect somehow, not just document the
code, or keeping them in sync will be an issue. Still, this doesn't seem
like quite the right thing to me:
> 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'm not sure about main-menu installing the deps; it will make putting a
progress bar over the install hard, and it makes things inflexible for
dealing with errors (both transient errors fixable by a retry and errors
of the package not available sort). Also from a UI perspective, "can't
install grub" is not as good an error message as "can't install boot
loader; here's the probably relevant part of the postinst error message",
and main-menu would be limited to the former.
Also packages like base-installer essentially depend on initramfs-tools
| yaird | initrd-tools, which couldn't really be expressed in a dependency
(unless we break the bits out into separate udebs somehow).
Maybe instead we should have some kind of
"satisfy-target-deps grub-installer" thing that pulls the list of packages
to apt-install out of the Target-Depends line. Then in the rare cases where
you need to install yaird | initramfs-tools, you can still specify using
anna-install instead. Or we could even even allow the deps to be ORed as
long as the caller choose which one to install:
Target-Depends: yaird (>= 0.0.12-3) | initramfs-tools | initrd-tools, linux-2.6 | linux-2.4
satisfy-target-deps base-installer --with yaird linux-2.6
satisfy-target-deps base-installer --with initrd-tools linux-2.4
(Am I overdesigning yet? Oh and one problem with this would be cases
where you needed to specify ordering, or install package A, do something
else, and then install package B.)
main-menu could still be aware of the Target-Deps, and if they couldn't
be satisfied it could skip menu items or whatever, so the installer
could dynamically deal with older systems like you're trying to do,
although I think neither of us is quite sure how that would work yet.
BTW, I also think that queueing behavior doesn't go very well with the
"Depends" relationship, but that's a minor quibble. Might be best to
name the field something not Depends though. Target-Installs?
--
see shy jo
[1] He said ambiguously.
Attachment:
signature.asc
Description: Digital signature