Repository feature proposal

Daniel Veillard veillard at redhat.com
Mon Oct 20 06:55:26 UTC 2003


On Sun, Oct 19, 2003 at 07:31:24PM -0400, Jeremy Katz wrote:
> 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.   

  Totally agree. You also refetch if you hit an unavailble mirror.

> 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. 

  That file doesn't have to be updated frequently, once per fedora core
release ought to be sufficient, honnestly even if the file grows a lot
it really not a big deal.

> 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.

  Really, in my perspective it's really smooth, at least for Red Hat
mirroring, it's in my biased opinion by far the easiest distro to mirror !

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/





More information about the fedora-devel-list mailing list