Repository feature proposal

[Nicolas Mailhot]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message num?riquement sign?e.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20031020/0adb23a6/attachment.sig>