Bug#620064: apt: please drop dependency on gnupg
On Tue, Mar 29, 2011 at 21:30, Carsten Hey <carsten@debian.org> wrote:
> * David Kalnischkies [2011-03-29 20:03 +0200]:
>> On Tue, Mar 29, 2011 at 18:32, Carsten Hey <carsten@debian.org> wrote:
>> > please drop apt's dependency on gnupg.
>> >
>> > There has already been some discussion in related bugs #387688 and
>> > #558784.
>
> I suggest a possible plan to get rid of the gnupg dependency without
> breaking things below, without reading yours before and then compare
> both:
>
> 1. apt and d-a-k both depend on gnupg in a stable release.
>
> done
>
> 2a. apt does support a new way to handle keys.
>
> done, even in Squeeze if I understood your mail correctly?
Support was added in 0.7.25.1 -- some bugfixes occurred later,
so to be save assume squeeze version of APT (0.8.10.3) provides it.
> 2b. d-a-k drops the dependency on gnupg and still uses apt-key in its
> maintainer scripts
>
> not done
Yeah, either d-a-k or APT can remove the gnupg dependency, but not both
as otherwise you will have in new installation the problem that gnupg is not
around to manage the trusted.gpg file…
I mean, APT could remove it now without changing anything - and d-a-k
can do it after implementing 2c, but if it is done before the key will be not
available for verification…
>> For me a plan looks more like:
>> - switch all keyring packages to store their keyrings in the new (=squeeze
>> supports it) trusted.gpg.d directory - at best even more fragments if it
>> makes sense, e.g. oldstable keys in an other file than the one for testing.
>> Links are fine, too.
>
> This is 2a and 2c from my list above.
>
> As long as the old interface is not removed and the other keyring
> packages depend on gnupg, there is no need to touch them now. Switching
> them can be done later. Prerequisite for this is that apt-key fails in
> a sane way if gnupg is not installed.
It doesn't currently (command not found), but after all, what is a
'sane way' to fail?
apt-key would need to fail, causing the maintainer script to fail, so
the package
fails to install. The alternative is 'just' printing a warning, which
nobody will see…
>> (- remove the apt dependency from all keyring packages)
>
> I don't think there is one.
debian-ports-archive-keyring for example, but all the others, too.
Expect d-a-k of course, this would be a circle dependency…
>> (- downgrade APTs d-a-k dependency to a recommend)
>
> If you want to make d-a-k and gpgv optional, I would let apt recommend
> both. In this case, ensuring that debootstrap and cdebootstrap install
> both in their minimal variants might be useful (people could still
> remove these packages).
>
> I have no opinion whether d-a-k and gpgv should be optional or not.
Its the connotation of #558784 - be able to decide on your own which keys
to trust, so you properly don't want to automatically trust new keys.
And as you said chroots or embedded systems might like it, too.
So a Recommends would in my eyes be a better fit than Depends
as APT can work without it - just not the security features in it.
d-a-k will be still around in all but very unusual cases because of
being 'important' and recommends being installed by default.
>> - close all three bugs mentioned in this bugreport here
>
> The d-a-k one can be closed immediately if its maintainers do the
> upload. Alternatively, you might want to extend (retitle and describe
> what apt needs) it to also include adaption of d-a-k to the new apt
> interface. Or you just file a new bug about this if you prefer it this
> way.
>
> Without knowing the details, I guess #558784 can be closed after all
> keyring packages have switched to the new interface and the old one has
> been disabled in apt. On the other hand, carrying the old interface
> a while in Debian might be useful for third party keyring packages.
> Then #558784 could be closed after all keyring packages in Debian have
> switched with the rationale that only unsupported third party packages
> using deprecated interfaces trigger it. But as already said, I don't
> know the details of this bug.
Its just d-a-k's keys which are added again and again with its special
handling in apt-key update, so if this is gone that bug can be closed - or
in other words: Implement 2c and be done with it as we wouldn't need to
call apt-key update then…
Best regards
David Kalnischkies
Reply to: