up2date problems (use a mirror)

[Nicolas Mailhot]

Le mer 14/01/2004 à 14:07, Jef Spaleta a écrit :
> Nicolas Mailhot wrote:
> > 1. Redirects are useless for most repositories out there - they mostly
> > get their stuff on an http/ftp server they don't control so they can not
> > do this kind of magic
> 
> By 'most repositories' do you mean official fedora mirrors?

Of course not;) I meant other rpm repositories. My interest in a
redhat-only solution is severely limited (like most people's, else yum
and apt would never have prospered alongside up2date, redcarpet,
uprmi...)

> > 2. There is absolutely no need for the procedure to be interactive,
> > except for rare cases where there is a need for a manual override. Just
> > feed the download manager a list of mirrors and let it handle it,
> 
> There may not be a need for interaction with official fedora core
> mirrors, but since Fedora Core can't official acknowledge other
> repositories like livna due to packages of questionable US legal status

Which is exactly why I wrote 1.

> there will have to be some mechanism for interaction to add extra
> 'mirror files' for 3rd party repos after the install.

Sure. Having the user add mirror lists is a reasonable requirement.
Having him choose among mirrors or refresh lists once they are installed
is not.

>  And lets not
> forget that the client side needs to be able to regrab a mirrorlist
> periodically to get an updated list of mirrors, though whether or not
> thats needs to an interactive step is debatable.

Well, it's not;) Why should the user intervene here ? He already
indicated his interest in the repository, installed the project key, he
sure won't object to a new signed mirror list. Gratuitous interactivity
is evil.

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/20040114/178ef591/attachment.sig>