header/RPM mismatch

[William Hooper]

Fulko.Hew at sita.aero said:
>
>
> WARNING: Additional ranting ahead.
>
> "William Hooper" <whooperhsd3 at earthlink.net>@redhat.com on 04/30/2004
> 11:08:31 AM added:
>
>
>>Fulko.Hew at sita.aero said:
>>
>>> <RANT ON>
>>> But both tools should be using the same config file!!!
>>
>>So yum should loose features and use up2date's config file (not very
>>portable to non-RH systems), or should up2date loose features (RHN, apt
>>support) so it can use yum's config file?
>
> 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?

> After all, they are both supposed to do the same thing.

Again, KDE vs. Gnome, vi vs. emacs, etc.

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

> As a user, which tool am I supposed to use.
> The answer (right now is) is...
>
> a) we give you a pretty icon on your desktop, but sometimes it lies.
> b) when you click on the icon it runs up2date, but sometimes it lies
>    And it now lies about the packages sizes too!
> 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...

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

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

> So in the end you don't know what you've got,

rpm -q

> who's wrong, whats wrong
> or where and how to fix it.

They all use the same rpm database.

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

>   "A man with two clocks, never knows what time it is."
>
> Sorry, there just appears to be too much of the
> 'barely good enough engineering' going on here.
> Do one thing, make it work, then go on to the next.  Not:
> "It powered up in the lab once, ship it, its a legacy product."

I'm sorry, if you are not interested in new features why are you running a
test release?
[snip]
>>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?

[snip]
>>> Pick one and throw the rest away.
>>
>>Yes, I think you should pick one and throw the rest away.
>
> OK, which one? Which one works?  ...Neither.

In my experience both.

>> Fedora shouldn't because different people like different
>> packages.  What's this business with multiple GUIs?
>
> But you only run one GUI at a time.

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

>>  multiple editors?
>
> But if I had two different editors and one only handled upper case
> and the other only handled lower case, and both would randomly decide
> whether they would support punctiatoion, they'd both be pretty useless.

A analogy, but no link to the original subject.

>>  multiple browsers?
>
> And can you say 'built for IE' only?

Fedora doesn't ship IE.

>>For that matter, Fedora only ships two (up2date and yum) and both are
>>using the same format for backend repos by default.
>
> 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?

--
William Hooper