> It would be more symmetric to just have > > server0=url://server0/path/url > server1=url://server0/path/url > server2=url://server0/path/url > ... > > More descriptive, too, as server1 may not be a mirror but a different > server altogether, although one hopes that the requested RPM's and > groups are in the intersection of what the servers provide. that doesn't mesh with the model we already have. - I like the idea of collapsible and multiple servers. I also like the idea of servers providing SPECIFIC sets of files and not just being a grab-bag whence rpms arrive. so maybe something like: [serverid] name="laalalal" priurl=url://serverlalala/path alturl0=url://altserver/path alturl1 etc etc etc ad nauseum. the reason being I think the user might want to know if/when a server fails and my general opinion is this: if any one server-section fails completely (ie: is completely inaccessible) then the program should exit w/o doing ANY operation - this argument is easy - if someone did something bizarre (like stacking rhl 7.1, 7.2 and 7.3 in three different server-sections in a yum.conf they might be terribly surprised if the 7.3 server was down and they had random things "upgraded" bizarrely) I'm thinking of this in terms of reliability and I want any one section to be completely reliable. > > You can't. There are a few things you can do -- pinging the host, for > example, before trying the URL. However, the nature of TCP is that > certain classes of network failure are indistinguishable from a host or > port being down. The best you can do is wait for a TCP timeout on the > socket OR parse any error message returned from the socket if you get > it. The ping is primarily to avoid the wait for a TCP timeout if the > host won't ping. yah - and there isn't really a good way to keep this from sucking afaict. > > > I know how to tell if its bad, but down? > > I'm not sure what this means. A "bad url" could mean: no I mean specifically. We ask for the headers.info file and we get bad/stupid data from the server. That is the main judge of a server's correctness - if the headers.info file is good or not. > Finally, if you run out of hosts with required RPM's still not found, > handle it as an error -- sometimes is might be safe to proceed (the > missing RPM is something like PVM -- useful and desired, but not > critical to a post-boot system and can be added in later) and others it > might be something really important (like a kernel or glibc:-). Again, > humans will likely have to judge which is which, although some yum users > may be ill-equipped for the judgement. no I think I won't want that. I'd rather not have a case where an automated, nightly run of yum eats someone's system b/c a server was down. I think the general rule to follow should be: if we can't get to any server/mirror in a single server section we exit w/error if we can't get a headers.info file for any server-section we exit w/error if we can't get a header that the headers.info file claims exist we exit w/error. if we can't get an rpm that the headers.info file claims exist we exit w/error. if we get an rpm that fails the gpg/md5 check we exit w/error. in general I want the default case to be "do nothing but tell you about it" rather than "try our best to continue despite the servers spewing lies and filth". It might cause more work for a user but I tend to the "don't break stuff" camp when it comes to installing things. -sv
