header/RPM mismatch

[Fulko.Hew at sita.aero]

... some context snipped for brevity...

>> If yum is supposed to replace up2date, then its config file, should be a
>> superset
>> of up2date.
>
>Who said yum is supposed to replace up2date?

If yum is not to replace up2date for updating, then why does it exist?
What itch is _it_ scratching that up2date
wouldn't/shouldn't/couldn't scratch?

Or is it another case of 'Not Invented Here' syndrome?

>> After all, they are both supposed to do the same thing.
>
>Again, KDE vs. Gnome, vi vs. emacs, etc.

but KDE and Gnome do _not_ do the same thing, and they do not
use the same config files, and they are not infered to work together
(except for the rhn applet that does work on both task bars.)

As for vi vrs emacs, they both operate on the same kind text files,
and when your done editing your file with one, the file is still readable
and usable by the other editor, so thats not a valid analogy.

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

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

>> e) Ohh, sometimes up2date hangs... Well just re-install, maybe it'll
>>    work.
>
>Have a reproducible situation?  A bug number?  I've been using up2date on
>FC1, FC2Test2, and FC2Test3 and I don't recall any hangs.

Yes, 100% reproducible since yesterdays's daily RPM fetch.
... while typing this message, I tried it again, and it no longer
hangs.  :-(  Maybe some of my earlier playing with the header
directories has resolved something... I don't know....
But the 'there are 2 packages to fetch, but you can only select
one of them' issue still remains.

>> d) If you get frustrated by the now broken up2date and the GPG issues
>>    you resort to using yum.   But sometimes _it_ lies.
>
>So if "you resort to using yum" why do you think it should replace
up2date?

Because I don't know which tool I _should_ be using.  :-(

I'd like to use the rhn_applet and up2date because:
a) thats what I used with RH7.x, 8.x, 9.x
b) it always _used_ to work
c) its on the desktop and its pretty,
d) and most of the time it works (or at least it did,
   ignoring the 'size reporting' issue and the "GPG error' issues.

But now that doesn't work so I have to use yum,
which gets me a 'little' further.

>> So in the end you don't know what you've got,
>> who's wrong, whats wrong
>> or where and how to fix it.
>
>They all use the same rpm database.

Sorry, I was talking about the various update notice facilities
and updating processes, not their end product.

>> I don't mind having choices, but at least one of those choices should
>> work, and if the others don't.  Then they shouldn't be supplied.
>
>Both work for me.  YMMV.

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

... snip ...

>I'm sorry, if you are not interested in new features why are you running a
>test release?

Because I want some of those new feature, but call me selfish...
I also don't want some of the old features broken. ;-)
Like up2date, or USB hotplug.

>>So set up multiple rsync jobs and have a human check that the first is
>> done?
>>
>> No, set up one job that rsyncs the RPMs, and then rsyncs the headers.
>
>And the case of headers being release on the main site after the first job
>is started is resolved how?

If there is a dependency and synchronization requirement on the
updating facility, then rsync is 'inappropriate' to use to maintain
mirrors in order to ensure 'system integrity'.

>>>Yes, I think you should pick one and throw the rest away.
>>
>> OK, which one? Which one works?  ...Neither.
>
>In my experience both.

That _used_ to be my experience, but since the virgin install of
test3, this no longer seems to be the case (and its not just me,
count at least 2 occurances here in Canada).

> If you are trying to run up2date and yum at the same time you might have
> just answered your own question.

Then I'm back to asking which one _should_ I be using?

... snip....

>> But neither of them use the same front end database and neither
>> seem to work right... anymore.
>
>Both use a yum repo and both put transactions into the RPM database.  What
>database are you talking about?

The directories where current and ancient headers and rpms are saved:

/var/spool/up2date
/var/cache/yum/development/headers