Bug#476532: debian-archive-keyring: unconfigurable due to missing gnupg
Hello,
sorry for my last email; Something very bad happened to your mail, so I
received a mail with only one word "give".
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:
> >>> Package: debian-archive-keyring
> >>
> >> It's apt that is failing not debian-archive-keyring... and
> >> debian-archive-keyring does recommend gnupg ...
> >
> > That's not entirely correct: see
> >
> > O: dpkg: error processing debian-archive-keyring (--install):
> > O: subprocess post-installation script returned error exit status 127
> >
> > 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).
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).
> >> 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.
BTW I also consider bootstrap the most crucial action of the three you named,
because repairing a f*cked up install is usually easier than a failed
bootstrap. (OT story: I once installed Debian on a friend's computer.
Everything went fine till bootstrapping failed, because it insisted on
downloading from the network although it was running from a DVD. I was able
to make it work by running debootstrap manually, but I couldn't resume the
installer so I had to configure the network, modules and install the kernel
and lilo manually. It was not a pleasant experience.)
> > 1) apt Dep: d-a-k, d-a-k Dep: gnupg (this was the situation before you
> > dropped the dependency on gnupg)
> >
> > 2) apt Dep: d-a-k, apt Pre-Dep: gnupg (this is really awkward)
>
> Why does it need to be a Pre-Depends is it not enough to have the
> packages unpacked (by having a Depends: gnupg)?
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):
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).
BTW what about the other proposals? Do you think they're infeasible?
Regards
Jiri Palecek
Reply to: