On Sun, Jun 06, 2004 at 06:51:36PM +0100, Carwyn Edwards wrote: > >Another example: lets say I run a custom kernel on a cluster of > >machines. I keep that kernel in my local repo. It takes me some time > >to patch and update it when a new kernel comes out so it lags the > >stock kernels. If my repo is down one day, poof, I have a kernel that > >breaks my cluster. > > Is this a valid counter example?: > > Lets say on that same day upstream released a security update which was > _really_ important to ship to all machines. Lets then say that I had > exclude=kernel in all the respository definitions apart from my local > repository. > > If yum did have "carry on if a repositroy is unavailable support" would > the end result not be: all my machines would have the security update > and would _not_ have the upstream kernel that I did not want? There are two real problems with this approach. The first is that it doesn't scale well. In this case, every time I want packages X, Y, and Z to be taken from repo-1 rather than repo-2 (or later), I not only must make repo-1 sort higher than repo-2, but I must ALSO list all of those packages as excludes in repo-2, repo-3, repo-4, etc. If I have 5 repos and 20 such packages (which are not unreasonable numbers), it becomes ugly quickly. The second problem is a psychological one. If this option were available (and I don't think I'd consider it as the default), then every thinks-he's-the-shit 18-year-old on the planet would be telling newbies to turn it on because it's "more convenient" and makes you less sensitive to "minor problems". Lots of people could end up hosing their systems because they don't understand the subtle implications. This is one of the major design philosophies of yum that Seth adopted and I completely agree with... it's almost as extreme as "make yum incapable of screwing up your box". -Michael -- Michael D. Stenner mstenner@xxxxxxxxxxxxxxx ECE Department, the University of Arizona 520-626-1619 1230 E. Speedway Blvd., Tucson, AZ 85721-0104 ECE 524G
