On Thu, 20 Nov 2003, Jim Perrin wrote: > Actually, what I've run into seems to be a python module problem, in when > it trys to pull the headers. I'm not sure if the proper module exists for > debian, or if it's simply due to the ancient version of python included in > debian/stable. I'll keep digging, and post what I find. Somebody posted earlier today asking what yum's advantages were relative to apt and friends. I didn't respond but this indicates one of them in a nutshell: "ancient version of python included in debian/stable". Yum gives you a broader range of choice at the stable end, or has up to now. Because of the layers of control (and control over layers) it provides with respect to repository lists, and because it appears that a lot of primary development teams are "yummifying" their primary package distribution sites, it seems likely that in the near future yum will provide one with a great deal of control indeed and provide relatively easy and low risk pathways to remain current on whole branches of distribution trees without destabilizing your enterprise. I was very intrigued to observe the Mozilla response earlier today -- upgrade mozilla to current by the simple expedient of slapping a mozilla repository entry in your /etc/yum.conf, and (we hope) thereafter automagically install updates as they appear in the mozilla tree. I'd also have to say that in some ways "we ain't seen nothin' yet". Yum is being very aggressively and intelligently developed. APT is a relatively mature tool, but maturity also creates a degree of inflexibility as more and more add-ons rely on a high-end API that was developed long ago. Yum so far has been developed as an intermediate layer on top of a very low level tool (rpm), and still has relatively little add-on-ware that rely on its API. In fact, its API in some sense isn't even fully defined except by its man pages, and is utterly open to change as discussions on this list indicate. Consequently it can evolve far faster with minimal impact. Yum 2 is already well advanced over yum 1, but yum 3 is where things will get very interesting indeed. Complete changes in the way header information is managed and a whole lot more. Should be exciting. Yum by its mere existence is also stimulating the APT team, Red Hat, maybe Mandrake (all of whom have high end tools in the same space) into rethinking lots of things, which is likely a very good thing. Is yum "better" than up2date, apt, urpmi? Hard to say, and possibly even a matter of taste, as all of these likely CAN be used to accomplish the basic tasks of managing an installation in a more or less automated way. However, most of the sysadmins of large scale networks and compute clusters on this list seem pretty happy with yum. As the yum article I posted yesterday makes clear, it is VERY EASY to set up a yum repository yourself, install the yum client on your LAN, and "instantly" have complete revision/update control of your entire network. Even a relative newbie to systems administration can likely manage it. To a pro, it is a piece of cake and chock full of the very features they'd ask for, added by a professional systems administrator (Seth) at the request of or with patches provided by professional systems administrators who use yum themselves (maybe 80% of the list). This is arguably the final difference. Yum is a professional toolset from the outset. It can be used by a systems administrative novice -- indeed it is designed so that it will automatically maintain systems owned by people who are utterly clueless about the command line if installed from an RPM built by somebody who does (with the appropriate yum.conf and chkconfig %post). However, it was designed top to bottom to facilitate the administration of large-scale networks of linux systems, INCLUDING those belonging to clueless users on which the toplevel admin has no root control, by systems administrators. I don't know all the details of the other tools, but I don't think any of them were developed in quite this way. up2date is clearly a corporate tool designed to tie Red Hat users to a specific Red Hat supported revisioning process. urmpi seems to do a similar sort of thing for Mandrake. APT appears to come from the other end, to permit users to completely install and update their systems from a single monolithic repository tree. In this yum has transcended it yup roots and is pretty much completely divorced from distribution and designed as much to support the real needs of real sysadmins as anything else. r-is-for-feeling-religious-today-gb -- Robert G. Brown http://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@xxxxxxxxxxxx
