[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Repository feature proposal



On Sun, 2003-10-19 at 17:48, seth vidal wrote:
> > So people can add tier2 or tier3 mirrors if they know about them.
> > Tier2 or tier3 mirrors can even provide complementary descriptors people
> > just drop in their config dir alongside the "official" list. (they can
> > even roll up their own packages that will do just that).
> 
> > A list, even if it's woefully incomplete one is much better than a
> > system where we just "hope" the user will "find" a better source than
> > ftp.redhat.com (hint - most people don't bother and hit ftp.redhat.com
> > directly)
> 
> incomplete isn't the issue - it's woefully out of data that's the
> problems. mirrors in fail-over only work if they are identical.

Mirror information is a problem that has to be solved, for a variety of
reasons.  My initial thoughts are that someone needs to step forward to
work with the mirrors to maintain a list (our IS guys try, but they're
far too overworked to really be able to spend significant amounts of
time on this -- I'm sure smooge will jump in to ditto this ;)  Then, we
can make the list available via http in a standardized location (for the
Fedora Core repository, probably http://fedora.redhat.com/something) and
then the first time you run an update program, it snags the current list
of mirrors -- likely with a built-in set of defaults that you know isn't
going to go away, just in case you can't get to the mirror data for
whatever reason.   

But there's going to have to be a lot of data in that mirror data file,
especially if we want to go the next step and have the installer able to
pull the file and use it to provide you a list of potential install
sources for an ftp/http install. 

Even completely discounting using with various tools, though, something
has to be done to make using mirrors sane.  The current way things works
provides lots of frustration for users and mirror admins alike, at
least, IMHO.

Cheers,

Jeremy




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]