Le dim 19/10/2003 à 23:48, seth vidal a écrit :
> 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.
That's not a problem here. Remember - we are talking about mirrors of
packages. You can evaluate a mirror freshness pretty easily by comparing
the metadata it declares to the master site metadata.
> 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.
It's less questionable than having people choose a mirror in a list by
country and have them "assume" the mirror is up-to-date.
If you give the package manager the full mirror list it can find pretty
easily what mirrors are usually up-to-date and accessible form you
network location (of course checking for better mirrors every once in a
while is good to, and comparing mirror freshness to the master site
should happen often)
> 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.
I think it is but maybe I'm biased.
Surely breaking it in lots of key=value pair will make it *less*
editable, not more.
> 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.
No. It's a reason why apt *works*.
How can you expect your download manager to work if you don't feed it
the necessary info ? (and one can disagree on what info is necessary or
not - when people have been taking the pain of making some info public
for a long time that's a pretty good indicator this info is needed.
> 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.
Please. What the hell the defaults have to do with this ?
You won't get people to mirror all arches because you want to simplify
your config file. You won't get them to reorganise their tree structure
just for RedHat - for big mirror sites RedHat is just a small part of
their ftp. You won't get Mandrake/Suse/etc change their ftp structure to
accommodate you - and some people here need to target more than
RedHat-only (up2date was a big flop for 3rd-party repositories because
it was so RedHat-specific).
I've given you a half-cooked example and I freely admit it may be far
from perfect. Just give me yours and I'll tell you if it fits my needs
(as a end-user, sysadmin and member of another third-party packaging
project. I will take whatever technical solution that solves my
problems, even if it's not the one I pushed myself;)
Cheers,
--
Nicolas Mailhot