Packages installed by --install-packages end up in final target without apt metadata

[jw-rav]

This can cause inconsistencies and might confuse unrelated subsystems.

For example: I added emacs-nox to the server ISO as an aid to investigate and fix on the fly problems caused by my autoinstall user-data.

The files from the emacs-nox package and even the postinst-created update-alternatives symlinks ended up in the target system, forcing emacs-nox to be run instead of emacs-gtk, even though apt was showing that emacs-nox is not installed at all.

Even worse: the fix is not exactly straight-forward, since "apt remove emacs-nox" will just say that there's nothing to do (apt thinks emacs-nox was never installed, right?). So to fix the problem , I had to:

1. install emacs-nox
2. remove emacs-gtk
3. install emacs-gtk
4. remove emacs-nox

Even more confusing is that dpkg metadata seem to have survived into the target-system, since "dpkg -L emacs-nox" happily lists all the files.

IMHO, packages installed by --install-packages should

1. either not be forwarded to the target system
2. or their apt metadata should be forwarded as well.

[mwhudson]

This will be caused by layering nonsense, if you install something into the minimal layer that updates /var/lib/dpkg/status in the minimal layer, but the next layer has its own /var/lib/dpkg/status which overrides the one from the minimal layer (it might not be exactly this which is happening, it'll be something along these lines). I'm not sure there's much that can be done about this in general, unfortunately.

[dbungert]

was the intention only to have emacs-nox in the live system? install-debs will target the installer layer instead of the base one, so won't affect the target system, albeit you have to specify .deb filenames.

maybe install-packages should take a layer argument, or at least have a live equivalent.

[jw-rav]

was the intention only to have emacs-nox in the live system?

Yes, emacs-nox was meant to be available in the installer environment as an aid to investigate and fix problems with the autoinstall environment. In the target system, full-grown GUI-capable emacs is installed which fails to be called because of the leaking alternatives thing.

install-debs will target the installer layer instead of the base one, so won't affect the target system, albeit you have to specify .deb filenames.

Bu this will not use the repository which is available in the installer system?

maybe install-packages should take a layer argument, or at least have a live equivalent.

To be honest, I have a hard time to understand this layering thing from the available description. Maybe somebody can provide a more thorough description of this layering thing?