Re: up2date stupidity

If you look at it from a purely Open Source point of view, I would tend
to agree.  Looking at it from Red Hat's point of view, I disagree - the
client was designed to take advantage of a business offering from Red
Hat, and so there would only ever be a single authoritative package
source.  (This of course ignores fancy games one can play with DNS
round-robining and other high availability techniques to give more than
one machine the same name and/or IP.)  So in this way, the original
design of the client was such that there never needed to be more than a
single server consulted.

        If you can get a multiple-server client working, go for it -
I've personally looked at it, and it's not as easy as it seems...  there
are way more issues that appear suddenly regarding completeness and
correctness of channel repositories.

On Sat, 01 Feb 2003, Jonathan S. Shapiro wrote:

> [Off topic]
> 
> In pondering the design of up2date, I'm struck by a question:
> 
> Does anybody *else* think that it was short-sighted that up2date will
> consult only a single server?
> 
> Never mind back-up servers. I'm thinking that I'ld like to publish a
> channel for the EROS stuff and let people subscribe to that without
> forcing them to grab all of their RedHat updates from my server as a
> side effect.
> 
> Conceptually, it shouldn't be hard to modify up2date to associate a
> server with each channel individually. Am I missing something painfully
> obvious?
> 
> 
> shap
> 
> _______________________________________________
> Current-server mailing list
> [email protected]
> http://lists.dulug.duke.edu/mailman/listinfo/current-server

-- 
Thank you,
John Berninger

Systems Administrator		[email protected]
Department of Mathematics	Box 8205, Harrelson Hall
NC State University		Raleigh, NC 27695
Phone:  (919)515-6315		Fax:	(919)515-3798

GPG Key ID: A8C1D45C
        Fingerprint: B1BB 90CB 5314 3113 CF22  66AE 822D 42A8 A8C1 D45C
--