[CentOS] yum vs up2date
mailing-lists at hughesjr.com
Wed Sep 6 23:13:22 UTC 2006
On Wed, 2006-09-06 at 13:34 +0800, John Summerfied wrote:
> Johnny Hughes wrote:
> > On Wed, 2006-09-06 at 08:35 +0800, John Summerfied wrote:
> >>Which is better? Why?
> >>I know yum is the official update mechanism here and in Fedora Core, but
> >>that doesn't make yum better than up2date any more than Windows NT was
> >>better than OS/2.
> >>Let's try to keep the discussion objective:-)
> >>I'm asking, hoping for some insights into why RH might (apparently) be
> >>moving to yum in preference to up2date (yum is now used within Anaconda).
> >>Other than general discussion, I'd also like to know what I'd muss by
> >>using up2date on CentOS.
> >>I'll start with this:
> >>What has yum that provides this functionality:
> >>up2date -d -u
> > The up2date that is used in CentOS is not like the up2date for RHN ...
> > it is in fact a bastardized version of old (2.0.x) yum repos. There are
> > backend repos that are not nearly as polished as RHN for yum and repomd
> > in up2date. The up2date for RHN is as good as yum ... however the
> > up2date using yum repos is not nearly as good. For example, obsoletes
> > did not work until we fixed it in the 4.4 update.
> Where does the up2date in Fedora Core 3 sit in this?
FC3 is past end of life, does it matter :)
however, the obsoletes code in up2date for either the yum type repo or
repomd type repo is broken there as well.
> > I am currently working on the yum-plugin-downloadonly to address that
> > specific issue.
> Does it get source too? That's about third on the list of things I like
> to do.
No ... but in the centos repos, neither will up2date do that.
In order for that to work (in up2date or yum), the SRPMS need to be
inside the $ARCH directory. In CentOS they are one level higher than
Starting with 4.4, we have linked the centosplus SRPMS directory down
one level for x86_64 and i386 so that it can be included in the metadata
generation. Try testing things from there, as SRPMS should be
available. Right now, the best I can tell, yum does not do anything
We need a plugin for that ... can someone figure out a plugin that will
take the rpm and figure out the SRPM, and download it. We would need to
also include where the downloaded SRPMS go (maybe a location defined in
the plugin.conf file).
> > Up2date also can not use the mirrorlist option which provides 10 GeoIP
> > based mirrors that failover based on (if you install the fastestmirror
> > plugin) speed.
> I really don't like the mirror list I've seen in Fedora Core. It pulls
> stuff from all over, Europe, Middle East - mostly, it seems, about as
> far away from Western Australia as possible.
CentOS shared our mirrorlist program with the Fedora Developers. Fedora
is reworking (or just reworked) their mirrorlist select program to
include GeoIP data. Their new program is not DIRECTLY based on ours
(and I think theirs is python ... ours is perl), however our design and
concept did influence it.
That is why I stressed GeoIP and the fastestmirror plugin. You will get
close mirrors and they will be timed so you get the one that responds
the fastest to your individual computer the day that you run it.
To see the Australia mirrors, do this:
You do not have to specify cc= as it will be based on the IP Address of
the connecting computer, but if you do specify it, it will override the
> I prefer the Debian approach; I choose a mirror. In Australia, IAPs
> commonly have a peering arrangement; content from within the peer
> network isn't charge against download limits. While (AFAIK) all members
> of WAIX (the local peer network) are in WA, not all IAPs in WA are members.
Well ... what if that mirror is not updated yet. The other advantage of
the mirrorlist system is that only UPDATED mirrors are shown. If a
mirror does not get updates, it will not show up on the list. When it
does not have the same content as master, it is removed and mirrors are
checked at least once an hour.
> > Up2date does not have protectbase or priorities capability.
You didn't mention these ... and they allow you to add 3rd party repos
and still protect your base so you don't update items in core ... but
you can update other stuff.
> > Up2date does not have a GUI capability like yumex.
> I've never used yumex, do I can't tell whether up2date's GUI capability
> is like yumex's.
> > yum is MUCH better than up2date for CentOS.
> As I mentioned elsewhere, installed 4.3 just before 4.4 came out. I'd
> uch rather have downloaded the packages overnight (triggered by cron)
> than type the commands in through my modem line.
Run yum via cron ... it can be turned on to do just that via this
chkconfig yum on
> GUIs aren't very good through modems.
Lastly ... in RHEL5Beta1 ... there is no up2date ... there is yum-2.9.x.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.centos.org/pipermail/centos/attachments/20060906/64dae5d8/attachment.bin
More information about the CentOS