On Tuesday 10 May 2005 15:45, Johnny Hughes wrote:
On Tue, 2005-05-10 at 13:14 -0600, Greg Knaddison wrote:
On 5/10/05, Lamar Owen lowen@pari.edu wrote:
My complaint isn't as much with the repository as it's with yum itself for blowing chunks and completely failing.
The problem isn't yum ... it is the 304 status code from apache
Well, one can argue semantics, but it takes two to tango. While apache shouldn't be sending that code, perhaps, yum is still responding to the code in an inappropriate manner (if the file hasn't changed, use the local copy, this being repomd.xml we're talking about).
In fact, there is a discussion on this topic already: https://lists.dulug.duke.edu/pipermail/yum-devel/2005-May/thread.html#114
Already on too many mailing lists. Not another. I just finally got rid of my last Fedora Core box and have unsubscribed from the Fedora-list (and -test and -devel) quagmire. Cut my mailing volume significantly.
Seth has responded with some reasons why simply noting that a repo is down and moving on isn't a good idea. I'm not familiar enough to say whether or not his reasoning makes sense, but I generally do respect his opinion.
I agree with Seth on this one ... if one repo doesn't work, you could get software installed from a repo where you don't expect it to come from. So I think it is perfectly reasonable to require manual intervention if something is broken.
I've looked closely at the whole strawman of 'if one repo doesn't work, then you might get software installed from a repo where you don't expect it to come from' and found it full of holes. Unless your local repo (which is the common cause of this scenario) bumps epoch, your locally generated packages (or your preferred packages from other repos) can and will get overwritten and updated by other repos if those other repos deal in that package. And there is significant package overlap to be had: particularly in the case with kde-redhat.
Been there, done that, with mixing ATrpms, PlanetCCRMA, FreshRPMs, and DAG on Fedora Core 2: it was a rat race between the repositories: update, and DAG updates a package; update again and you got PlanetCCRMA's package; update a third time, ATrpms blows in; update the fourth time, and now Matthias' handiwork graces my disk. In many of these cases packages from one of the four repos had conflicts with the packages from one of the other: file conflicts, as in ATrpms had things packaged where the package owned a different set of files from the FreshRPMs package and the updated package from FreshRPMs can't install. I cleaned up manually so many times that it became ritual to clean the package cache before doing an update so that I could manually rpm -Uvh --force --nodeps afterward (after parsing the output of a straight rpm -Uvh, of course). This is using apt to perform the updates; I had too many issues with FC2's yum to continue using it. Not that apt was perfect, because it wasn't even close. But it was better than manually updating daily, that's for sure.
So I call that whole 'blindsided update' scenario a strawman: it can (and does) happen even if all your repositories are in working order; skipping a repository due to a repo failure somewhere has never caused me to have this problem, and I have done synaptic upgrades with skipped repos numerous times. This problem has indeed occurred for me, but always when ALL of my selected repositories are up and running normally.
The solution could be apt-style pinning. If I pin say fftw3 to be a local repo package, then when Dag updates his fftw3 package (before I have a chance to bump the version on my local copy) all my GNUradio code won't quit working: GNUradio requires a single-precision compile of fftw3, which is not the default. So I generated local packages for fftw3. If an update blows in, then it quits working. If I can tell yum (I CAN tell apt this already) to never update fftw3 from any other source than the local repo, I'm ok, otherwise I'm not. If the fftw3 package is pinned to local, then, even if the local repo is skipped due to error the Dag copy of fftw3 won't overwrite.
For those who run local modified repos this could be golden, and they would probably just want to blanket pin all local repo packages. Hmmm, to simplify things over the way apt deals with it, a repository directive 'My Packages Trump Your Packages Even If I Am Not Here' would be the ticket and prevent the strawman above from ever happening. Or a general 'repository priority' scheme where the admin can give repos priority and even pin a package down to only be updateable by that repo.
But yum was originally built to be a system UPDATER more than a general purpose system installer/package manager: it's now being used in a capacity for which it wasn't originally intended.