[CentOS] Yum repomd.xml error

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 at 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.
-- 
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu