header/RPM mismatch

[Fulko.Hew at sita.aero]

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.  After all, they are both supposed to do the same thing.
The bigger issues is that headers are saved in two different directories
on your system, so its guaranteed to get out of sync.

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).
e) Ohh, sometimes up2date hangs... Well just re-install, maybe it'll
   work.
d) If you get frustrated by the now broken up2date and the GPG issues
   you resort to using yum.   But sometimes _it_ lies.

So in the end you don't know what you've got, who's wrong, whats wrong
or where and how to fix it.

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

Just because certain vendors do that, doesn't mean the Linux community
should stoop to their levels.

>> and the master site and the mirror site should be
>> consistent within themselves ie. I better have the RPM that
>> my hdr file points at.  Ie. copy header files last.
>
>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.


>> Also I don't think, by design you should allow either system to 'get
into
>> a mode' where the various tables, databases and directories can 'get out
>> of sync' like this.
>>
>> And while I'm at it...  This business about three different updating
tools
>> that
>> use three different techniques, and 3 different stores, is a piece of
...
>> 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.

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

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

>  multiple browsers?

And can you say 'built for IE' only?

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