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 that. 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 with SRPMS. 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: http://mirrorlist.centos.org/?release=4&arch=i386&cc=au&repo=updates 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 default detection. > > 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 command: 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: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.centos.org/pipermail/centos/attachments/20060906/64dae5d8/attachment-0005.sig>