-----Original Message-----
From: fedora-test-list-bounces(a)redhat.com
[mailto:fedora-test-list-bounces@redhat.com] On Behalf Of
Fulko.Hew(a)sita.aero
Sent: Friday, April 30, 2004 10:58 AM
To: For testers of Fedora Core development releases
Subject: RE: header/RPM mismatch
WARNING: Additional ranting ahead.
"William Hooper" <whooperhsd3@earthlink.net>(a)redhat.com on 04/30/2004
11:08:31 AM added:
>Fulko.Hew(a)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.
--
fedora-test-list mailing list
fedora-test-list(a)redhat.com
To unsubscribe:
http://www.redhat.com/mailman/listinfo/fedora-test-list
Hmm, Im sorry you've had troubles. I don't think either tool is broken,
however. I have used both successfully on FC1 to FC2T3. As long as both
tools are pointed to a mirror (the same mirror), I have never had any
problems.