header/RPM mismatch

[Michael A. Peters]

On Fri, 2004-04-30 at 14:17, Fulko.Hew at sita.aero wrote:
> > up2date and yum have different feature sets.
> 
> As an end-user, I don't know that, and I don't see that,
> unless I really dive into the documentation of both.

As an end user, you don't need to worry - because they both contain
repos that will have the same packages.

Only when you start adding repos will there be a difference, in which
case you should have dived into the documentation.

> The apparent, and implied use is that both tools can be used
> to update your system to the 'current' level.  Perhaps both
> do more and different things above and beyond this basic function,
> but most people look to them to perform nothing else but
> 'updating to current'.

And when updating the current, it doesn't matter which you use.
But yum is there for those who prefer it to update - which is going to
be people who don't mind the cli.


> Whats wrong, is that for some reason (that I do not understand)
> this morning I had the various apps reporting the following
> various needs:
> 
> package           rhn        up2date      yum
> -------------------------------------------------
> perl-XML-Twig     need it    need it      need it
> perl-Net-DNS      need it                 need it
> gaim                                      need it
> rpmdb-fedora                              need it
> 
> I'd have to think that if they were all using the same info,
> they'd be reporting the same thing.   Wouldn't they?
> The fact that three different apps are reporting three different
> 'apparent' states of my system is disconcerting.

I'm guessing that if you had waited, the ones that didn't need it soon
would have. the mirrors they point to probably are not all in sync.

> 
> My answers are... I don't know, I don't know, I don't....
> I installed whatever the 'system' told me to install.
> If I needed something else, 'the system' should have either come
> with it, or told me so, or the release notes....
> Otherwise, how am I to know?
> I know this is a test release, but sorry...
> people should not have to be fighting these types of issues past the
> first hour of a new release..

That's what bugzilla is for. Usability bugs are bugs too.

> 
> I would pick and only use one, but...
> Sorry, with three different tools telling me three different
> things make me believe that potentially none of them are right.

Why believe that?
More likely - they use different mirrors or one simply hasn't updated
its header cache.

> 
> >Again, why should two completely different programs use the same
> processes?
> 
> Because they are all intended to report the same information:
>    "what RPMs I should be updating"

And they are doing that - according to the header information that they
have.

> 
> Hammered, just means slow or no data...  It should never mean 'incorrect
> data'.

It also could mean they are having difficulty getting the updates to
mirror.

> 
> OK, so noted.  But on the other hand, if they are independent, and the
> result is in the RPM database, I should be able to run both interchangably
> but not simultaneously.

I actually did that for awhile.
up2date would have trouble downloading a package - so I would quit
up2date and yum install package to get that package. Worked well.

Then I decided to just remove the up2date applet from my dock, because I
liked yum better.

> 
> True, if two apps are using two different repositories, I would expect
> two different answers, but since they are not, they are using the same
> repositories, and the same mirrors, I expect them to report the same thing.

If they are using the exact same mirrors, then it's possible that one (I
suspect up2date) is caching its header info and not really checking
every time. Maybe when the server is being slammed and it doesn't get
all the headers, it just goes with what it _did_ manage to get. Which
may be why some packages didn't show that they needed updating.

-- 
Cheap Linux CD's - http://mpeters.us/linux/