up2date problems (use a mirror)

[Jef Spaleta]

Geoff Teale wrote:
> I do agree that some dynamic look-up of mirrors would be a much better
> solution than having users edit files in /etc.

Considering that the default urls pointing back to redhat.com are
actually redirects, it seems plausible to me that there is some intent
to be able to provide some dynamic mirror rotation behind those default
redirect urls...though i've seen no actually discussion confirming my
deductive powers. And if the right people haven't already thought that
far ahead, i hope they don't have me /dev/null'd in their procmail
filters and have a light bulb moment. I certainly don't take credit for
the idea...but it seems a pretty obvious use of the redirect urls. 
Though I have no idea if 'infrastructure' is in place for that, nor do I
claim a full comprehensive of any ancillitory concerns like security or
syncing issues and what the current view from the official mirror
maintainers about being part of a round robin redirect. It could be more
complicated than i think it is....but I'd love to here informed opinion
on the matter..even if its just a chorus of rasberries.  

Of course a client side selection of mirrors would also be useful. But
here you have decisions to be made about when the user gets presented a
choice, is this first boot worthy?...and whether the mirror list you get
to choose from is a static one or is pulled from a central location at
selection time. I'd imagine the specifics about how a client would
actually negotiate a mirror list would be best left to the specific
mailinglist associated with the client tool in question. Though having
an official mirrorlist xml file format or equivalent for tools to parse
would be a trivial but noteworthy discussion. Having all the tools agree
to use the same mirror file format would be nice.

Then there is the 3rd option..which i think is going to be a much more
lively debate. About having a point and click way for people to go to a
website of mirrors (or even 3rd party repos) click a link..and configure
their update tool. This opens up things to have community webpages of
'unofficial' lists of repositories like livna which cant be official
spoken of in the distro because of US legal constraints. But I bet
someone has a rational argument saying this sort of things presents a
higher security risk. But I certainly don't know how to evaluate the
risk of this in a selinux powered FC2 world(okay I admit i wouldn't know
how to evaluate the security risk in an un-selinux FC1 world...but I
hope selinux affects the security of this sort of action.)  I don't
expect all the tool writers to agree that this sort of thing is
appropriate...but it seems to fit in with how up2date is suppose to be
used, so it seems appropriate for consideration for whatever is going to
be the up2date gui equivalent in fc2.

-jef
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20040113/5750bc3c/attachment-0002.bin