Repository feature proposal

Nicolas Mailhot Nicolas.Mailhot at laPoste.net
Sun Oct 19 21:39:07 UTC 2003


Le dim 19/10/2003 à 22:43, seth vidal a écrit :
> > > also - the mirroring information is tricky b/c most mirrors won't know
> > > about the other ones - mirroring information is probably best left OUT
> > > of the information for any one repository.
> > 
> > But the core org knows about it's official mirrors. And this official
> > mirror list should be made available to the end-users download manager
> > so it can choose automatically the closest/less loaded available mirror
> > (maybe even spread the load between several mirrors).
> 
> untrue - they know about tier1 mirrors - but not tier2 or tier3.

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)

> > Relying on the users to uncomment a mirror in a list means most people
> > won't bother and just hit the mother site.
> 
> have you seen how the mirrors are used for red hat's mirrors?
> they use the first one in the list that responds in < 2s.

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.

> <snip xml sample>
> and that seems simple to you?

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.

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)

The point is to have full repository info in a single file so the
package downloader can make the correct download decisions without user
intervention, and the user can choose channels without having to go
elsewhere to learn what "fedora extra" means".

Spec files may seem verbose too - they are information-rich so the
system can take care automatically of updates, and the user forget all
the king of manual checks he'd have to do otherwise.

Note how the complementary intranet descriptor was small - it could be
because xml enabled to reference stuff in the master repository
descriptor. People may need a special app to write a full-blown
descriptor - but they won't just to tweak one.

> > If the download manager logic is properly implemented it will always use
> > the new mirror instead of the others, because if you won't have added it
> > to the list if it's worst than the official ones (ie it will always be
> > closer/have more bandwidth available than the others).
> 
> the amount of data you'll have to include is growing and growing.

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.

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/20031019/ba73b8ef/attachment.sig>


More information about the fedora-devel-list mailing list