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@xxxxxxxx> 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
