On Saturday 02 May 2009 20:30:55 Bryan J Smith wrote: > Alan McKinnon wrote: > > Ah, but YUM is a front-end to rpm and gaining traction. > > Huh? I know a lot of people here live in "home consumer" > land, but when is the last time you'all looked at CIO, IDC > and various business deployment numbers on CentOS and > RHEL? You do know YUM has been the standard for such > for over 2 years now? And that's not including the great > number of Enterprises that have been using YUM for the > last 5 years.
I think you misunderstand me, I'm not talking about the last 6 months worth of numbers, I'm talking years - as in the numbers of years between LPI exam updates and the support life of distros like RHEL. YaST was the earliest integrated rpm front-end to my knowledge. Then urpmi or whatever Mandrake called it way back then. YUM came after them, and thank god it did, for one thing it meant we could dump up2date. It's so much a better option that so many distros see it as well. And there are heaps of RHEL4 machines still out there running up2date. I don't keep up with the day to day release Changelogs on Red Hat so correct me if I'm wrong but I don't think RH backported YUM to RHEL4 "Gaining traction" is not necessarily defined as "starting to get going right now". > It is in as widespread use as APT, and that's been the case > for years now. > > > rpm itself is (with good reason) an objective on its own. > > In enteprises, YUM commands are used 10x more than RPM, > just like APT over DPKG. This viewpoint is beyond aged. > > YUM is to RPM as APT is to DPKG. I know that Bryan, I didn't start in this game yesterday. I have a very full understanding of how the various package managers fit with their lower level tools and which tools are conceptually comparable with each other. > Not only did YUM start > on a different distro than anything Red Hat, but there are > few RPM-based distros that have not adopted it. YUM > v3 is over 3 years old. Even YUM v2 releases from 5+ > years ago had "localinstall" so one should *NEVER* > run "rpm -ihv," *PERIOD*. I continue to chalk up un- > appreciation for YUM outside of Enterprises due to lack > of exposure and total unfamiliarity. Who's being unappreciative? If you deduced that from my post, then either you read it wrong, or I was unclear in expressing my opinion about it, or both. I'm glad YUM is there, I just don't think it warrants an objective. And that's more due to resulting exam bloat and similar competing products that anything to do with it's technical quality. > YUM also has a plug-in architecture. Long story short, > combined with RPM 4.6 and Spacewalk with delta'ing, the > days of full package updates are extremely dated. > > > If we include YUM in the objectives, I suppose we should > > include urpmi and YaST as well. > > If you can prove that URPMI and YaST have over a 30% > marketshare in Enterprises and SMBs like YUM, then I'd > say yes. But I know the two combined don't even come > close. CentOS used YUM even before RHEL did with its > RHN plug-in, and many enterprises did the same. So where do we stop, where is the line that prevents exam bloat? Historically, LPI had apt, dpkg and rpm on the objectives. For better or worse, that's how it is. Perhaps it's because of apt's age and the need to know dpkg was long gone while running rpm was still common. But that's splitting hairs, let's look at what exists in the real world. You make a good case for YUM's importance. Let's survey it amongst the expert groups that determine what goes in the exam. Let's list dpkg, apt, aptitude, all the various synaptic variations, plus the simple point-click gui interfaces that show up on desktop distros, emerge, ebuild, tar and maybe even throw in BSD ports for good measure, and see how the expert groups rate them by relative importance. I've stated my considered opinion already, that YUM on the exam is not viable (which has nothing to do with it's quality). OTOH, conceptual knowledge of what rpm is doing under the covers is important, if only to know how dependencies tie together and how to interpret package manager errors. Knowledge of the tool itself is not *that* important. > Covering APT without covering YUM, and ignorant home > consumers relaying the igorance that Red Hat uses RPM > in comparison to APT, gets really old. In fact, it's the > quickest way to end a job interview in a great majority > of enterprises. I still cannot believe people who still > telegraph their unfamilarity so quickly. Is that directed at me? or to the unwashed masses in general? If it's the former, then I'm confused as to how you came to that conclusion, I can only think that you made assumptions about data I did not mention. I didn't deem it necessary to post a weighty tome on what I thought of all reasonable aspects of all package managers. > Given sheer marketshare, for your own benefit, please > don't proliferate this. If you don't believe, compare the > marketshare of YUM-based distros versus APT-based > distros, let alone the percentage of RPM-based distros > that are YUM-based. ;) Well, as I said above, I never said or thought what this paragraph conveys. -- alan dot mckinnon at gmail dot com _______________________________________________ lpi-examdev mailing list [email protected] http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
