[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#476532: debian-archive-keyring: unconfigurable due to missing gnupg



Jiri Palecek wrote:
> Hello,

Hi

> On Friday 18 April 2008 01:00:26 Luk Claes wrote:
>> Jiří Paleček wrote:
>>> On Thu, 17 Apr 2008 18:52:06 +0200, Luk Claes <luk@debian.org> wrote:

>>> BTW recommends are totally irrelevant when we talk about configurability.
>> Indeed, but d-a-k needs apt to configure, gnupg only indirectly...
> 
> I don't think the question is about directly/indirectly. Imagine a 
> (fictitious) situation, where pkg B has an optional feature requiring pkg C 
> (therefore, B recommends - or even suggests - C). Pkg A uses B, but needs 
> crucially that optional feature. In this case (I think), it would be 
> appropriate to declare the dependency although it's indirect, but, an 
> agreement between the maintainers in question could make it possible to 
> avoided (eg. by creating a dummy package A-with-feature).

I thought we were talking about a real issue instead of an imaginary
one? The one you show above is not comparable as apt is running apt-key
in it's postinst as well, so it needs gnupg no matter what d-a-k would
have as dependencies.

> But we are not in such a situation, because apt needs gnupg to configure, too 
> (it would have failed if it was configured before d-a-k, which is, however, 
> impossible, because apt Dep: d-a-k). And the whole thing of dropping the 
> dependency, IIUC, was made to allow installations of debian w/o gnupg. Adding 
> gnupg as a dependency of apt (which is Essential) wouldn't help this purpose, 
> so it's even more important for the maintainers to agree how to make it work 
> (and then do it).

AFAIK apt-key is supposed to be changed to only depend on gpgv instead
of gnupg...

>>>> You mean apt-key from the apt package... so I'm reassigning the bug.
>>> The situation is: apt-key needs gpg to work, apt-key needs d-a-k, apt
>>> calls apt-key in postinst, d-a-k calls apt-key in postins.
> 
>>> The only solutions I see are:
>> Hmm, you're only talking about bootstrapping here, not about
>> installation, nor about upgrading...
> 
> No, I talk about them, too. I talk about traces of dpkg actions that shouldn't 
> fail and should produce correct results. Also, upgrading is not an issue here 
> since none of the dependencies in question are versioned.

d-i uses d-a-k-udeb which still doesn't fail AFAICS, so back to
bootstrapping (aka using (c)debootstrap).

> It is sufficient to have them unpacked (at least I think). The problem is 
> that "apt Dep: d-a-k, apt Dep: gnupg" doesn't warrant this. Consider the 
> following trace of dpkg actions (U - unpack, C - configure, initial state of 
> the packages is purged):

Did you try this?

>  1: U d-a-k
>  2: U apt
>  3: C d-a-k
>  4: U gnupg
>  5: C gnupg
>  6: C apt
> 
> which is permitted with those dependencies, but fails in step 3 (apt is 
> unpacked, so you call apt-file, but it fails due to missing gpg).

apt-file is a very different package, I guess you mean apt-key.

> BTW what about the other proposals? Do you think they're infeasible?

They don't make much sense except as a hack if all else fails IMHO.

Cheers

Luk



Reply to: