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.
Actually one can be smarter than that - query all mirrors the few
first
times, record response time/freshness/effective bandwidth when
downloading, and use only the best sources after a while (re-doing a
full query every once in a while) I think autorpm did something like
this at one time.
and the heuristic was fairly questionable iirc.
Considering the information density yes (I won't say this is the
best
format, this is just something I cooked in 20s to show what could be
done - one should probably add a few gpg elements to register the keys a
repository is supposed to use for example).
If you look at real-world fedora.us usage for example this is the level
of info one finds today. I merely organised it a bit so a user could
read it easily instead of mastering obscure apt convention.
> if you're going to have that as the config file then you're going to
> need a program to edit/manage those.
A file for a big repository like Fedora will be long sure.
Now the syntax itself is simple enough people can tweak the files
easily.
I disagree - people have a hard enough time with key=value.
I don't think that file is human editable at all.
Sure it may seem heavy - but it's a lot less heavy than the
current
method where one has to read a lengthy doc describing syntax, another
describing channels, yet another describing mirrors, yet another one
what gpg keys will be used, etc (people hunting rawhide mirrors and/or
non-x86 ones know the pain)
bye current method you mean 'for apt'
this is just a good reason why apt's configuration is a mess, not why
this has to be done on the repo-side.
Maybe - just show me some of it is useless and I'll drop it.
Having people manually collect this info somewhere else doesn't make the
system simpler, quite the contrary.
the trick is combining the information density with sensible defaults.
This is why the gnome people have taken a lot of time trying to get
config options more sane - it is not a trivial undertaking.
-sv