Re: apt 0.6 in experimental
On Sat, Dec 27, 2003 at 11:47:56AM -0500, Joey Hess wrote:
> I've updated my local repositories to use signed Release files.
> mini-dinstall makes this quite easy. They look ok, but apt-get just
> ignores them. For example: deb http://kitenet.net/~joey/debian/ unstable/
> The key is 025BC58F, on wwwkeys.us.pgp.net.
> root@kite:~>apt-key list
> pub 1024D/30B34DD5 2003-12-03 Debian Archive Automatic Signing Key (2003 v2) <firstname.lastname@example.org>
> pub 1024D/025BC58F 2003-12-27 Joey Hess (apt repository signing key) <email@example.com>
> sub 1024g/CB0B34ED 2003-12-27
> root@kite:~>apt-get update
> Ign http://uqm.debian.net unstable/ Release.gpg
> Ign http://kitenet.net unstable/ Release.gpg
> Ign http://uqm.debian.net unstable/ Release
> Hit http://uqm.debian.net unstable/ Packages
> Hit http://uqm.debian.net unstable/ Sources
> Ign http://kitenet.net unstable/ Release
> Hit http://kitenet.net unstable/ Packages
Perhaps you should check the actual URL that apt is attempting to retrieve,
and make sure that you are placing the Release file in the correct place?
apt-get --print-uris update works as expected.
> apt-key add fails if there is no ~root/.gnupg. I don't habitually use gpg
> as root, so that was suprising.
Hmm...apt-key uses --no-options and --no-default-keyring to try to suppress
as much of that garbage as possible, but apparently it isn't enough. I
happened to have a ~root/.gnupg, so I didn't notice this.
We want to operate on a public keyring, only, and have no secret keyring or
trustdb. The current command line used is:
GPG="gpg --no-options --no-default-keyring --keyring /etc/apt/trusted.gpg"
--homedir /etc/apt might help a little, but it would complain about the
permissions, and we really don't want it to mess with any other files in the
first place. It shouldn't need a ~/.gnupg in order to work, but I tested,
and you're correct, it complains, even though it wouldn't actually use any
of the files there.