[6248] in Release_7.7_team
Re: Installers merged (and apt repository merger thoughts)
daemon@ATHENA.MIT.EDU (Geoffrey Thomas)
Sun Mar 1 02:17:53 2009
Date: Sun, 1 Mar 2009 02:16:55 -0500 (EST)
From: Geoffrey Thomas <geofft@MIT.EDU>
To: Tim Abbott <tabbott@mit.edu>
cc: athena10@mit.edu, release-team@mit.edu
In-Reply-To: <alpine.DEB.2.00.0902281837380.1796@vinegar-pot.mit.edu>
Message-ID: <alpine.DEB.2.00.0903010207050.28530@geminorum.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Flag: NO
X-Spam-Score: 0.00
> In the shorter term, geofft is working on a patch to reprepro that allows
> it to support signing an apt repository with two different keys. We would
> thus have our repository signed with both the Debathena and Athena 10
> signing keys for a transitional period, at the expense of having to
> maintain a patched reprepro on our upload server. This approach might be
> the most expedient way to merge our apt repository URIs without causing
> people to get "unsigned repository" errors.
The patch turned out to be smaller than I expected:
/mit/geofft/Public/reprepro-multisig.patch . I've tested it on the "apt"
directory in my public, i.e.,
deb http://stuff.mit.edu/afs/athena/g/e/geofft/Public/apt intrepid main
The two keys are key1 and key2 in the apt directory. If you install just
one of them, you get the following nonfatal but stupid-sounding warning
from aptitude update or apt-get update:
Hit http://stuff.mit.edu intrepid Release.gpg
Ign http://stuff.mit.edu intrepid/main Translation-en_US
Hit http://stuff.mit.edu intrepid Release
[...]
Reading package lists... Done
W: There is no public key available for the following key IDs:
F2F3560003CA5FD1
W: You may want to run apt-get update to correct these problems
When you do an install, though, there is no warning about the package
being unsigned, which is the thing we're most worried about avoiding
(especially on cluster systems).
It's worth nothing that you get a similar error about running apt-get
update (again) if you simply don't have a key for the repository at all,
so maybe we want to get upstream to give a better error message, and
possibly ignore the case of having not all signing keys while we're at
it.
If you want to test it against a non-aptitude client, there are two
packages in that repository: the patched version of reprepro and an empty
equivs package called "lol".
--
Geoffrey Thomas
geofft@mit.edu
