header/RPM mismatch

Fri Apr 30 19:58:54 UTC 2004

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

up2date and yum have different feature sets.

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

KDE and Gnome do the same thing (they are "Desktop Environments"). 
Because they are different programs they "and they do not use the same
config files, and they are not infered to work together", just like yum
and up2date.

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

up2date and yum operate on the same RPM files and when you are done the
RPM database is usable by the other.  What is not valid?

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

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

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

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

Must have missed that thread.

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

Which ever one you like.  That is what choice is about.

> 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

Already in bugzilla.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=107048

> and the "GPG error' issues.

See above.

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

Again, why should two completely different programs use the same processes?

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

It couldn't possibly be the fact that the mirrors (and main server) are
being hammered by people downloading the new test release...

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

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.

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

You seem to be wanting to make a dependency there.

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

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.

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

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?

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.

--
William Hooper