Hi Ben & Patrick,

Ben Hutchings <b...@decadent.org.uk> (2019-05-28):
> Control: tag -1 serious
> 
> On Tue, 2019-05-28 at 10:16 +0200, Patrick wrote:
> > Package: debian-installer
> > Version: 20190410
> > 
> > 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.

Right, thanks for the catch and the report.

> 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 think these effects are undesired. I'd suggest to use
> > "APT::Install-Recommends true" when installing the linux image.
> 
> 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.

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,
-- 
Cyril Brulebois (k...@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

Attachment: signature.asc
Description: PGP signature

Reply via email to