debian-installer doesn't install the Recommends of "linux-image-*".
Apparently, this is by design since [1].

The effects are:
1) For "buster", a clean install doesn't include "apparmor" and
"firmware-linux-free" (both are Recommends for "linux-image-*"). This
is curious, because [2] suggests "apparmor" is enabled by default,
while it actually isn't.
2) A future kernel upgrade initiated by "apt" _WILL_ install the
"Recommends", causing "apparmor" and "firmware-linux-free" to be
installed at that stage.

I think these effects are undesired. I'd suggest to use
"APT::Install-Recommends true" when installing the linux image.

[1] https://salsa.debian.org/installer-team/base-installer/commit/53e3722a1376c4777701e453d03491b8090fefd2
[2] https://www.debian.org/releases/buster/amd64/release-notes/ch-whats-new.en.html#apparmor

Control: tag -1 serious

There has (effectively) been a change in APT's behaviour since that
earlier commit.  "apt-get upgrade" does not install new packages unless
you use the --with-new-pkgs option.  However, the newer "apt upgrade"
command does install new dependencies and recommendations.

Because security upgrades sometimes introduce ABI changes and new
binary packages, we now recommend use of either
"apt-get upgrade --with-new-pkgs" or "apt upgrade" for all upgrades,
and since last year the installer uses the former.

I agree that it's a serious problem that AppArmor may only be properly
enabled later, and I'm upgrading the severity accordingly.

I think that for at least the kernel installation,
APT::Install-Recommends should be set to the same value it will have in
the installed system, i.e. dependent on base-installer/install-
recommends.

However, I think we should revert this commit entirely.  The current
default behaviour is that *any* security update or other stable update
will cause the installation of its recommendations where they weren't
installed before, and that is likely to be quite surprising.

Ben.
-- 
Ben Hutchings
Make three consecutive correct guesses and you will be considered
an expert.

Hi Ben & Patrick,

Ben Hutchings <ben@decadent.org.uk> (2019-05-28):

Right, thanks for the catch and the report.

This approach seems reasonable; feel free to go ahead on the commit,
upload, and possibly unblock request fronts. Given the current freeze
related hints, base-installer can be uploaded right away if you wish
to do so, that shouldn't impact the d-i release process for RC 2.

Cc-ing Steve who mentioned an interest in this bugfix; worst case I'll
deal with it myself in a couple of days.

Thanks everyone!


Cheers,

I think the revert will have to be deferred to at least a point
release.  As I understand it, we no longer want exim4 to be included in
a standard install.  Currently cron, mdadm, and poularity-contest
recommend exim4 or default-mta, and those recommendations would need to
be removed first.

For 10.0 now I will try to do the minimal fix for kernel installation.

Ben.