Legacy mirror structure

[Bill Nottingham]

Matthias Saou (thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net) said: 
> Jesse Keating wrote :
> 
> > Yes, difficult thing to think of.  Perhaps it would be feasable for the 
> > master mirror to hold the correct headers/ file that has SRPMS and debug 
> > stuff, but have a mirror.headers/ directory that is the result of
> > ignoring the SRPMS and the debug stuff.  I personally don't wish to
> > include debug stuff.  If the end user wants debug, they can download the
> > SRPM and build it themselves.  But a headers/ and a headers.nosrpms/ 
> > would be useful for mirror folks.
> 
> Well, currently, the (yum) headers for SRPMS are not used for anything
> AFAIK.

up2date has code to download the source RPMs for particular binary
RPMs, it just hasn't been ported to the yum backend yet. What
concerns me about multiple separate repositories for binaries, debuginfo,
and source RPMs is just the proliferation of channels that a developer
might need to subscribe to.

Of course, this is a more general point rather than legacy-specific.

Bill