[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Repository feature proposal

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]