New Key Repo Locations

[Jeroen van Meeuwen]

Jesse Keating wrote:
> On Fri, 2008-08-29 at 01:51 +0200, Jeroen van Meeuwen wrote:
>> If 9/ is excluded, wouldn't that mean 9/$releasever/*/os.newkey is also 
>> excluded? If it's not, then I guess there's no point in the new 
>> directory being created either.
> 
> Yes, if 9 is excluded (or included) that means the admin either doesn't
> care about 9 and doesn't want to mirror it, or explicitly cares about it
> and only wants to mirror it.  Either way I wish to honor those choices
> by not changing the top level directory where "9" or "8" will be.  This
> also means we won't have to re-file our export approval.
> 

So, if 9/ is excluded from, say, the hourly sync a mirror does (since it 
only needs to be mirrored once), the os.newkey/ won't end up on the 
mirror, which is my primary concern. (I guess this has been answered, 
partly, in another reply in this thread already).

>> Will the ISOs be respun to reflect the changes as well so that what is 
>> in os/ or in os.newkey/ meets what each of the ISO expects? I guess this 
>> is primarily relevant to respins, netinstalls and so forth, as the old 
>> RPM-GPG-KEYs will be in the root of those ISOs and I can only presume 
>> they are used, and people will want to use os.newkey/ as the tree to 
>> install from.
> 
> At this time, the isos will not be respun.  We will however re-sign the
> SHA1SUM file with the new gpg key.  We are certain that the content on
> the ISOs (and the numerous hard copies floating about) are safe.  The
> only content to be left in the repos these isos will be able to access
> out of the box will be the transition fedora-update release, and the
> fixed packagekit for gpg importing.  We'll also have mirrormanager
> direct all requests for the old dir directly to mirrors which we have
> ultimate control over.
> 

I'm not sure how that solves the net install use case, especially if 
mirrormanager is going to redirect to os.newkey/, as signatures used on 
os.newkey/ packages will not meet what the installer expects the 
signature to be on these files.

For the other part, where mirrormanager directs requests to mirrors we 
have ultimate control over... is this going to interfere with the local 
mirrors someone like myself may have set up at home and at multiple 
customer sites? E.g., will clients in these netblocks be redirected to 
mirrors the Fedora Project has ultimate control over, or am I 
misunderstanding what you are saying?

>> Has creating/composing an entirely new 9.1/ release tree been 
>> considered? I guess recreating the entire release tree is a PITA (jigdo, 
>> iso, torrent, foo) even though updates would not be included other then 
>> maybe the updated fedora-release package (with the new rpm-gpg-keys and 
>> new repo configuration files)?
> 
> It was considered briefly, but not very much.  Calling something 9.1
> would also have a bit of an assumption that we've fixed some bugs or
> otherwise made it a better release, which we aren't doing.  We're merely
> re-signing content and placing it in a slightly different directory, but
> it's still 9, not 9+something.  (ditto 8)
> 

This sounds to me like a not-really-technical argument. You're right in 
that the naming in releases/X.Y does imply a new and improved install 
tree. I think there's some other serious consequences to choosing to do 
it in the original X/ release tree though. I'm thinking, who gives a c* 
that there's not actually 'new and improved' content in the trees even 
though the naming suggests that there is, while it does carry an 
entirely new tree with ISOs and jigdo's and stuff that have the new 
signed content and make a full match between what you download and what 
you start using, like with a normal release.

Kind regards,

Jeroen van Meeuwen
-kanarip