... 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
On Fri, 2004-04-30 at 13:25, Fulko.Hew@sita.aero wrote:
... 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?
Let's get this straight. Yum wasn't written by red hat. It was written by me in large parts with contributions from a number of other people. I do not work for red hat. I work for duke and I wrote yum on my free time.
So yum is not a victim of NIH.
Let's move on.
-sv
On Friday 30 April 2004 10:25, Fulko.Hew@sita.aero wrote:
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?
For one, up2date cannot generate a yum header tree to run your own repository. For that you need yum-arch, which comes with yum.
-----Original Message----- From: fedora-test-list-bounces@redhat.com [mailto:fedora-test-list-bounces@redhat.com] On Behalf Of Fulko.Hew@sita.aero Sent: Friday, April 30, 2004 12:25 PM To: For testers of Fedora Core development releases Subject: RE: header/RPM mismatch
... some context snipped for brevity...
Then I'm back to asking which one _should_ I be using?
... snip....
fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-test-list
Basically, you use the one you want to. Whichever you like better. There is no right or wrong answer here. I personally prefer yum. I have tried up2date, yum, apt, and they all work fine, I just prefer yum. Very easy to use.
On Fri, 2004-04-30 at 10:25, Fulko.Hew@sita.aero wrote:
... 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 is intended for those who are use to the Windows way of being notified that there updates, and taking action.
yum is for those of us who like the crontab, and see the value of having yum downloading (but not installing) the updates for us - so that when we check, and there are updates, and we decide what we want - we don't have to wait.
yum is also an excellent place for third party repositories. Sure, you can do them in up2date as well, but if you use experimental repositories - you'll get the thing flashing all the time.
On Fri, Apr 30, 2004 at 01:25:20PM -0400, Fulko.Hew@sita.aero wrote:
If yum is not to replace up2date for updating, then why does it exist?
As much as I hate to bring car analogies into a computer discussion...
This is like saying "if the Ford F150 is not to replace the Ranger, then why does it exist?". They do different things. Sure the primary function of yum and up2date is the same (just as for the F150 and Ranger) but they differ in significant ways. These ways may not be significant TO YOU, but they ARE to some people.
What itch is _it_ scratching that up2date wouldn't/shouldn't/couldn't scratch?
Well, I'm not even sure up2date existed when Seth started hacking on yum. When up2date came into common use, many people preferred yum because it let you use multiple repositories and didn't require you to pay to set up your own server. Maybe up2date satisfies this now as well. I don't know, but the list goes on and on. I'm sure up2date has features that some people really like, as well.
-Michael
Michael Stenner wrote:
On Fri, Apr 30, 2004 at 01:25:20PM -0400, Fulko.Hew@sita.aero wrote:
If yum is not to replace up2date for updating, then why does it exist?
Well, I'm not even sure up2date existed when Seth started hacking on yum. When up2date came into common use, many people preferred yum because it let you use multiple repositories and didn't require you to pay to set up your own server. Maybe up2date satisfies this now as well. I don't know, but the list goes on and on. I'm sure up2date has features that some people really like, as well.
i do not know when seth started with yum but rhn-applet and up2date are doing a good job since a few years for me
$ cat /etc/redhat-release Red Hat Linux release 7.3 (Valhalla) $ rpm -qf `which rhn-needed-packages up2date` rhn-applet-1.0.6-11 up2date-gnome-2.8.40-3.7.3
on fc1
$ rpm -q up2date yum rhn-applet up2date-4.1.21-3 yum-2.0.5-1 rhn-applet-2.1.4-3
http://ftp.redhat.com/pub/redhat/linux/6.1/en/os/i386/SRPMS/up2date-1.0.1-1.... http://ftp.redhat.com/pub/redhat/linux/6.2/en/os/i386/SRPMS/up2date-1.13-1.s...
On Sun, May 02, 2004 at 02:22:39AM +0200, shrek-m@gmx.de wrote:
i do not know when seth started with yum but rhn-applet and up2date are doing a good job since a few years for me
up2date (of old) was built around the Red Hat network and central services that work extremely well for enterprise/paid support type stuff. It didn't support yum/apt and the like until Fedora 1. Yum always supported yum (suprise) but not the more enterprise focussed stuff.