header/RPM mismatch

[William Hooper]

Fulko.Hew at sita.aero said:
>
>
>> 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.

Again, this applies to a number of things.  That doesn't mean that one
should go away.
[snip]
> I only have a single system image to update, therefore updating the
> system is purely functional and could/should be devoid
> of 'asthetic' flame wars.

Never seen an apt/yum/up2date or deb/rpm/tgz flamewar, huh?
[snip]
> 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?

Are they using the same info?  By default up2date will use a random mirror
(possibly a different one each run).  rhn-applet (which I assume is what
you mean by rhn) I'm not sure, I will have to look.  Yum uses
download.fedora.redhat.com.

> The fact that three different apps are reporting three different
> 'apparent' states of my system is disconcerting.

Please give us more info.  How about the output of:

yum check-update
up2date -l
rhn-applet-tui
[snip]
> 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....

It does come with the other GPG keys.

> Otherwise, how am I to know?
> I know this is a test release, but sorry...

Exactly, which means as a tester the decision of what keys to trust falls
on you.  I definitely don't want up2date automatically importing beta or
test keys on a production system.

A better question to come out of this is why isn't yum doing gpg checks
out of the box?

> Because they are all intended to report the same information:
>    "what RPMs I should be updating"

Just to take this reasoning to the extreme... apache and IIS should use
the same configuration info because they both "serve HTTP"?

The sooner you get past the idea that up2date and yum are different
programs, even though they have some functional overlap, the better off
you will be.

[snip]
>>It couldn't possibly be the fact that the mirrors (and main server) are
>>being hammered by people downloading the new test release...
>
> Hammered, just means slow or no data...  It should never mean 'incorrect
> data'.

Well, missing headers or packages on the mirror: no data
Truncated package download: slow data followed by no data

>>That is what testing is about, finding out if anything broke.  If you
>> want
>>new features and no bugs (yeah, right) wait for the release.
>
> Sorry M$... no bugs should always take precedence over new features
> especially since the bugs have been found and documented.

Got a bug number from bugzilla yet?  You are still running on the
assumption that all your issues are the programs when it is more likely a
mirror or rawhide tree issue.

> Unless we test the software, report the problems, _and_ have the problems
> fixed, there will be no point in waiting for the next release, because
> the bugs will still be there in the new release.
> (Just like the 'update/size' bug that hasn't been fixed since Core 1).

Is a pretty cosmetic issue, but IIRC it only happens in 1 place now.  The
metadata hasn't changed so it still doesn't have the size information to
put in before the packages are being downloaded.
[snip]

>>Whichever one you want.  My point is that you don't run "both at the same
>>time" you are running up2date, then running yum.  Just like KDE and
>> Gnome.
>
> 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.

Exactly.

-- 
William Hooper