Bug#886473: marked as done (apt-setup lacks a dependency on gnupg)
Your message dated Mon, 9 Sep 2019 14:29:18 +0200
with message-id <20190909122916.GA31803@korn.westfalen.local>
and subject line Re: apt-setup lacks a dependency on gnupg
has caused the Debian Bug report #886473,
regarding apt-setup lacks a dependency on gnupg
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)
--
886473: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886473
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: apt-setup
Version: 1:0.134
Using additional repositories by preseeding with apt-setup/local0/repository
and apt-setup/local0/key is currently broken, causing the installation to
fail with a non-obvious error message at a late stage of the install. The
reason seems to be that apt-key fails on line 38 of generators/60local,
since apt requires gnupg to be installed for the attempted operation.
Until recently, base-installer has always pulled in gnupg. Presumably due to
some other package depending on it. This is no longer the case.
As long as 60local is implemented as is, and the example-preseed.txt
documents the use of additional repositories, apt-setup should ensure
installing from additional repositories works.
My undestanding of prepare_gpg_home() in cmdline/apt-key.in of apt is that
it is an active choice to not have apt itself depend on gnupg, thus making
it the responsibility of the caller.
I can see that there is a wishlist bug #877013 addressing a similar issue.
Don't know more about it's status than the bug report reveals, but would
consider this is a separate issue of higher severity since it now actually
breaks functionality rather than merely is about adding more granular
security controls.
A work around which helped me and might be interesting for other bitten by
this bug is to add "d-i base-installer/includes string gnupg" to the preseed
file.
Unfortunately I cannot provide a patch, since I do not fully understand
which mechanism to use to make a udeb of the installer environment pull in a
package in the base-install of the target system. None of the packages I
could suspect to be changed have seen any recent relevant commit activity,
so I can't figure out exactly what made this break. It should not make much
difference since it likely has been a missing dependency in apt-setup all
along.
--
/Martin
--- End Message ---
--- Begin Message ---
Version: 1:0.151
On Sat, Jan 06, 2018 at 03:22:41PM +0100, Martin wrote:
> Package: apt-setup
> Version: 1:0.134
>
> Using additional repositories by preseeding with apt-setup/local0/repository
> and apt-setup/local0/key is currently broken, causing the installation to
> fail with a non-obvious error message at a late stage of the install.
This was fixed in 1:0.151 (and was also backported to Buster 10.1)
Cheers,
Moritz
--- End Message ---
Reply to: