My proposal is to run a master mirror server for FL. An ISP has offered rackspace and bandwidth for such a beast. The layout I envision is this:
download.fedoralegacy.org/legacy/$releasever/SRPMS/ download.fedoralegacy.org/legacy/$releasever/SRPMS//base download.fedoralegacy.org/legacy/$releasever/SRPMS/updates download.fedoralegacy.org/legacy/$releasever/SRPMS/updates-testing download.fedoralegacy.org/legacy/$releasever/SRPMS/legacy-addons download.fedoralegacy.org/legacy/$releasever/$basearch/base download.fedoralegacy.org/legacy/$releasever/$basearch/updates download.fedoralegacy.org/legacy/$releasever/SRPMS/updates-testing download.fedoralegacy.org/legacy/$releasever/$basearch/legacy-addons
I'd be interested to see us include lingual and architecture support in those paths. Recall that the redhat storage paths are:
$releasever/en/os/$arch
I think they make a great deal of sense, and will prevent us from having to play "two-path-monte" or create ugly symbolic link farms if we need to make changes later.
====================================================
The following are my personal recommendations regarding the mirror structure.
IMHO, since long time ago RH merged all languages into a single distribution, I highly doubt we will go back to having multiple distributions for different languages. The earlier 7.x supported by Legacy is only a special case. For this reason I would suggest not using a language directory. Keep one layer of complexity out.
arch directory does make sense though. I am surprised they are missing from your original proposal you were the one that suggested arch i386 and x86_64 in IRC. =)
I am in agreement with previous posters in suggesting making the basedir "fedoralegacy" rather than just "legacy". This makes things more clear for mirror maintainers.
I would highly suggest going through at least another day of discussion and consensus for the mirror structure, since this is IMPORTANT. You need to live with it forever.
One note about when you write the Fedora Legacy mirror HOWTO document. Make sure that your package timestamps match exactly RH's main mirror, and make sure that mirrors use rsync option "-a" which will preserve timestamps among several other wanted options. This should allow mirror admins to use the hardlink tool (contained in the legacy-addons channel) to consolidate tons of space with their existing redhat and fedora.redhat.com mirrors.
I would suggest NOT holding the base SRPMS within the mirror tree on the Legacy master mirror. Just keep the directory empty. They are almost totally never needed, and if a developer really does need it, they can get it easily enough from any of the thousand existing RH/Fedora mirrors.
I am intrigued by the channel name "legacy-addons" rather than "legacy" currently used by fedora.us. It would be a little confusing to have both names exist. I suppose I could rename the channels on fedora.us, but unfortunately all existing users pointing there will need to upgrade their yum or edit their configurations.
I do admit however that "legacy-addons" is less ambiguous and very clear that it contains only add-ons, while "updates" does not. Thus I am thinking this is a good idea. Sorry existing users... but read below, since I am thinking to soon remove 7.2 and 7.3 completely from download.fedora.us for reasons of redundancy.
==============
Just to clarify about why download.fedora.us is maintaining a separate mirror structure from fedoralegacy.org. Below outlines my thoughts for future maintenance and distribution of fedora.us, and how it will continue to operate after FC2 when the Extras development and repositories are moved to fedora.redhat.com.
1) fedoralegacy.org's own mirror structure allows a separation of governace, security, build system, and responsibility of sysadmin duties. (Community no longer needs to rely on Warren. Warren does not go insane.)
2) I plan on automatically rsyncing legacy's updates and legacy-addons channel into the appropriate directories of download.fedora.us. This will allow existing fedora.us users to continue to get updates from repositories they had been using since 9 months ago for RH8, RH9 and FC1. Other existing repositories with an "updates" channel like freshrpms.net could do the same from legacy's "updates" and continue to serve existing users in a similar manner.
Existing users need only import the new FEDORA-LEGACY-GPG-KEY.
3) It is true that download.fedora.us 7.2 and 7.3 will be completely redundant to fedoralegacy.org's 7.2 and 7.3 since fedora.us never did make add-on packages for 7.x. For this reason I am thinking to simply remove the 7.2 and 7.3 trees from download.fedora.us. I'm hurting for space anyhow...
4) download.fedora.us will continue to serve RH8, RH9 and FC1 add-ons in the Extras channels stable/testing/unstable for users who wish to use them, while continuing to benefit from "updates" which are copied from legacy. fedora.us will indefinitely maintain security updates for RH8, RH9, FC1 Extras within the existing download.fedora.us tree, with the help of the Legacy team.
5) download.fedora.us will no longer be needed by FC2, since Extras will be moved to fedora.redhat.com. Then fedoralegacy.org will continue to handle "updates" for each distribution in their own mirror structure.
6) When FC2 goes EOL, fedora.redhat.com's Extras might also be frozen. Thus fedoralegacy.org may need to add an "updates-extras" channel in order to serve security updates to FC2's Extras. We will not need to discuss this until sometime during 2005 though.
7) fedoralegacy.org can continue to use bugzilla.fedora.us. That instance of Bugzilla is now being maintained professionally and should remain stable as a result. New products/components can be added to the Bugzilla to uniquely support Legacy development.
8) fedoralegacy.org should eventually fork their documentation into their own Wiki for draft & editing purposes while policies are discussed and agreed upon. Then maybe later docbook XML for nicely formatted finalized documents. This policy & process documentation writing is another job needed for fedoralegacy.org, and another chance for volunteers to contribute.
Comments? Questions? Please reply to both lists as this impacts both of our projects in the future.
Warren Togami warren@xxxxxxxxxx
