Lost ability to sign rpms

Description of problem:

With the recent gnupg churn, applying F14 updates, the system upgrades to a state where rpm --resign does not work anymore

Version-Release number of selected component (if applicable):
gnupg2-2.0.16-2.fc14.x86_64
gnupg2-smime-2.0.16-2.fc14.x86_64
rpm-4.8.1-5.fc14.x86_64
rpm-build-4.8.1-5.fc14.x86_64
rpmdevtools-7.9-1.fc14.noarch
rpmfusion-free-release-14-0.2.noarch
rpmfusion-nonfree-release-14-0.2.noarch
rpm-libs-4.8.1-5.fc14.x86_64
rpmlint-0.98-2.fc14.noarch
rpm-python-4.8.1-5.fc14.x86_64

Hopefully this will be fixed with the switch back to the gnupg-1 for the gpg binary.

Ah, actually the gnupg2 package you have already does not contain the compat gpg symlink. Please install the gnupg package.

If rpm needs this package to work it should require it

Have gpg users been notified they needed to change their package requires?

They should require the gpg binary and not the package. There was no change in requires when the switch from gnupg to gnupg2 was done so it should not be needed in the reverse direction either.

I also suppose that rpm does not require gpg explicitly to not bloat the minimum install for optional functionality as I do not think the --resign is used on most installs. Perhaps a special subpackage for rpm should be added that would pull the gpg requirement?

(In reply to comment #4)
> They should require the gpg binary and not the package.

Except yum people hate file requires and have spent quite a lot of time asking people to kill them in their packages. So it is not safe to assume gpg-using packages do not require it through a package name

(In reply to comment #6)
> (In reply to comment #4)
> > They should require the gpg binary and not the package.
>
> Except yum people hate file requires and have spent quite a lot of time asking
> people to kill them in their packages. So it is not safe to assume gpg-using
> packages do not require it through a package name

What the yum people hate is file requires outside those included in primary data as they require downloading the big otherwise unnecessary filelists data. Stuff in /usr/bin is included in the primary data which is always downloaded so it doesn't make much of a difference whether binary or package name is required.

Back to the actual issue... missing gpg dependency goes as far back in history that I can easily check for (RHL 7.0). Funny how long these things can stay lurking without apparently anybody noticing.

As it is, signing support can't be meaningfully split into a separate sub-package... so I guess I'll just have rpm require /usr/bin/gpg for now.

I meant a "virtual" or empty subpackage, that would just contain the requires and perhaps some documentation. Of course the signing support in rpm would have to fail gracefully preferably with a message to install the /usr/bin/gpg for it to work.

Having the base rpm package require gpg binary is really a bloat for a minimal installs.

Or if the require would be on rpm-build, it would be OK I think.

Fwiw, gnupg2-2.0.16-2.fc14.x86_64 isn't in f14 updates (or updates-testing) yet, pending readiness of existing update,
https://admin.fedoraproject.org/updates/F14/FEDORA-2010-12595

(Concern like those described here is one reason why I've asked folks involved to wait for the aforementioned one to go stable before issuing any updates re-instating gnupg v1).

(In reply to comment #8)
> I meant a "virtual" or empty subpackage, that would just contain the requires
> and perhaps some documentation. Of course the signing support in rpm would have
> to fail gracefully preferably with a message to install the /usr/bin/gpg for it
> to work.

That's what I meant with "not doable as is". Actually rpm does provide a semi-meaningful error message on missing gpg... but only when run in verbose mode:
[pmatilai@dhcp102 ~]$ rpm -v --resign /tmp/gnupg-1.4.10-2.fc13.x86_64.rpm
Enter pass phrase:
error: Could not exec gpg: No such file or directory
Pass phrase check failed

In normal verbosity level, rpm closes the stderr of the child forked for running gpg, effectively hiding the error message. No idea whether it was to avoid message spewage from some old version of gpg, with current versions it doesn't seem to make any difference on the output in non-error case. So might as well make the default case show errors too and improve the message while at it.

>
> Having the base rpm package require gpg binary is really a bloat for a minimal
> installs.
>
> Or if the require would be on rpm-build, it would be OK I think.

Well, rpm-build doesn't require gpg any more than rpm itself does - both only need it if you're doing signing on the box. And OTOH creating a sub-package for nothing but a single dependency seems a bit silly too.

A related issue is that AFAIK there's no particular reason for rpm to require gnupg-1.4, it could just as well use gnupg2 and that gets dragged in by yum already, so its likely to be present on even minimal installs already (unless you count mock buildroots)

OK, so perhaps it could try to exec /usr/bin/gpg and if not found /usr/bin/gpg2 then? Or the other way around?

Fedora 14 is EOL, in Fedora >= 15 rpmsign the packaging is a bit different and gpg is required where necessary.