header/RPM mismatch

[Fulko.Hew at sita.aero]

> 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.
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'.

> KDE and Gnome do the same thing (they are "Desktop Environments").

I guess you are correct.  Where the functionality of KDE and GNOME
overlap there should not be differences in configuration.
But desktops _are_ different, they are visible, they are personal,
so I give that a little more slack.

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.

... snip ...

>>>> The bigger issues is that headers are saved in two different
>>>> directories
>>>> on your system, so its guaranteed to get out of sync.
>>>
>>>Huh?  Neither needs the others headers.
>>
>> Its more like neither _uses_ the other's headers...
>> hence the duplication and inconsistency problems that result.
>> (see the final comment).
>
>But vi not using emacs settings is OK?  KDE not using Gnome settings is
>OK?  PostgreSQL and MySQL not using the same files?  What is the
>difference?  Why is it so important that these two programs use the same
>everything when there are so few examples of two programs that do?

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.
Thats why I don't know who to believe.
And yes, I know that rpm -q tells what I've got
But this discussion thread revolves around:
'which of these packages _really_ need updating'?
(Not a yum/up2date/apt-get/etc flame war.)

>>>> c) If you decide to carry on with up2date, you now have to ignore all
>>>>    of the GPG errors, because of... (well I don't know).
>>>
>>>Of install the correct GPG keys...
>>
>> What are the correct keys?
>> I installed test 3 from the release CDs and went through the
>> upgrade process.  Are there other manual, un-documented steps
>> that need to be performed to get rid of these GPG errors?
>> If so, please give me a link.
>
>Depends, what GPG keys did you install?  You are running a test release,
>did you install the test key?  You are trying to get updates from rawhide,
>did you install the rawhide key?

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..

>http://fedora.redhat.com/about/security/

Ok, I will review that tonight, and see what it says.

>> Because I don't know which tool I _should_ be using.  :-(
>
>Which ever one you like.  That is what choice is about.

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.

>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 both used to work for me too.  Its just that as the days
>> go by, and as we moved from test2 to test3, things are
>> degenerating (here).
>
>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'.

>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.

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).

> (w.r.t. header files and RPM files on mirrors....)
>You seem to be wanting to make a dependency there.

On the contrary, _I_ don't want to make a dependency between hdrs and RPMs
on repositories, but apparently there is one.  And so, it should/must be
dealt
with in a professional manner.

>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.

>Again I ask why two separate programs should be expected to use the same
>set of files.  What if you have up2date checking an apt repo?  or RHN?

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.

>You are trying to jam up2date and yum into the same mold, and they won't
>fit.  They are two different programs with two different ways of doing
>things.

But the same basic end result:
    "... You have the following list of RPMs to install:"