"Will Go Unnamed" wrotes:
> Yet another Update Manager (among others)
This is a perfect example of why I don't bother here. That one might
break my "top 10 list" (where #1 is "Ubuntu invented Network Manager" ;).
Yellow Dog Linux came up with an approach different than APT, and
Seth Vidal out at Duke improved on it. Red Hat agreed. Even
Novell agreed (years ago). Almost everyone agrees! Red Hat regularly
adopts "what works" and hires developers, especially if it is popular.
So what gives? *NO*ONE* uses RPM to manage their systems and nearly
*ALL* use YUM *UNLESS* they are using a vendor-specific repository
that requires another tool. But even Red Hat switched to a YUM
plug-in for RHN access. But Red Hat has supported YUM meta for
nearly as long as Fedora has been around, because of 3rd party YUM
repositories.
Alan McKinnon wrote:
> I think you misunderstand me,
I think you misunderstand YUM. Three (3) years ago, I might have
let this slide. Back then, people were "just waking up" to all the
community and commercial support for YUM meta, and OpenSuSE had just
moved to standardize on it.
Today? Sorry, I cannot even believe someone would have APT-DPKG and
not YUM-RPM. It would kill the credibility of LPI not to add it to
the next rev, because even Novell-SuSE supports it, and OpenSuSE
builds are released into a tree with _only_ YUM meta.
> I'm not talking about the last 6 months
> worth of numbers, I'm talking years
Okay, let's talk "years" ...
Almost seven (7) years for Fedora, let alone its originator
Around five (5) years for CentOS
Nearly three (3) of YUM v3, for RHEL and OpenSuSE**
**NOTE: YUM is the _exclusive_ meta for build tree access
in OpenSuSE (yes, Novell's own upstream)
I don't know of a RPM distro that isn't moving to support it,
if not the default. YaST marketshare in comparison is nothing,
and URPMI is definitely nothing**.
**NOTE: Nearly all sites I've been at with any Mandrake servers
have switched to RHEL/CentOS or Ubuntu LTS.
> - as in the numbers of years between LPI exam updates and the
> support life of distros like RHEL.
Dude, I don't know what world you live in, but YUM is _the_
standard now for RPM. Even OpenSuSE agrees as its build exclusive.
I brought this up years ago. Why? Because the sheer
marketshare in business usage even three (3) years ago (before
the YUM RHN plug-in was official in RHEL), was high. I can't
make up the numbers.
Again ... "I told you so" just doesn't cut it.
> YaST was the earliest integrated rpm front-end to my knowledge.
YaST was largely a SuSE commercial-specific access tool, just like
Up2date for RHN. Neither were designed to be universal tools.
We don't touch Up2date for the similar reasons we don't touch YaST.
YaST was proprietary until Novell bought SuSE, and although Up2date
was open source, the code for the Red Hat Network (RHN) backend
was not fully open sourced until last year.
I'm talking marketshare of open source tools and meta here. YaST
has added YUM because of its sheer popularity, over any other
solution. YUM meta is the _exclusive_ for OpenSuSE's build trees,
OpenSuSE development has been built around YUM meta for years now. ;)
It is the defacto standard in the community for the RPM back-end,
period. That hasn't been disputed for years now.
> Then urpmi or whatever Mandrake called it way back then.
Again, marketshare here.
Mandrake has lost a lot of customers and, correspondingly, developers.
Red Hat plucked a lot of them -- increased size from 2,200 to 2,800
employees from 2008-Feb to 2009-Feb. Yes, over 25% employee growth
in this recession.
Driving the point home ...
Everyone thinks Red Hat "does its own thing." That's absolutely not
true. Red Hat "hires" people who solve the problems that Linux has,
and they believe have the best solutions. The developer of YUM was
just one of those as well.
> YUM came after them, and thank god it did, for one thing it meant
> we could dump up2date.
Again, Up2date is a RHN-specific tool. It was never designed to
be "general," it's specific to RHN. And what had RHN 100% switched
to? YUM. There is even Spacewalk-YUM support for older RHEL releases
now.
> 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.
But many Up2date versions *DO* support YUM meta. This has been
the case since only shortly after Fedora came around. ;)
I'm only going to say this one more time ...
Absolutely 100% of all my clients I've been at for nearly the last
four (4) years are _all_ using YUM for _all_ of their RPM
distributions. Even the ones connecting to RHN with older
RHEL releases are using YUM, and definitely the last few years
have I seen corporations with RHEL+SLES using YUM meta for their
tree (regardless of the tool).
This includes as a "corporate-wide standard" when both RHEL and
SLES are in-house over the last few years. APT-RPM and Smart Package
Manager (SmartPM or just "Smart," which I think is actually "the best")
have had some share, but YUM v3 has pretty much killed it.
Not everyone is connecting to RHN or running their own
RHN Satellite Server with their own, custom/clone channels, so
they can use up2date (as well as config and other tools in RHN).
Many are maintaining their own YUM repos, even when they may
have RHN Satellite and up2date in usage.
Again, even up2date added YUM meta support years ago. Red Hat just
made the switch formally to the YUM tool itself. Red Hat _hates_
maintaining anything that doesn't have upstream buy-in.
> 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
But RHEL 3+ _do_ support YUM meta. YUM meta is the defacto
default tree in nearly every distro now, includine OpenSuSE.
No offense, but Red Hat only waited for YUM v3 and the full RHN
plug-in to put it under full Service Level Agreements (SLAs). That
decision and development was completed over three (3) years ago,
and has been out in RHEL 5 since the mid-2006 Betas.
YUM v3 was released three (3) years ago. It's well liked by ...
well .. everyone in the RPM world! ;)
Does Red Hat support RHN access with a plug-in for YUM on RHEL 4
under Service Level Agreements (SLA)? No. RHEL 4 shipped in early
2005, over four (4) years ago. Does Red Hat offer a YUM for RHEL 4? *YES*
Where you been? YUM meta support has been in RHEL 3+.
Just because the Red Hat Network (RHN) itself has a legacy interface
default until 2006 before RHN v4, and YUM didn't ship in RHEL 3-4,
doesn't mean that YUM meta wasn't supported in RHEL 3-4. ;)
Because virtually every community effort was moving to YUM some
five (5) years ago! RHEL 4? Dude, RHEL 4 has been in "maintenance
mode" for over two (2) years. Red Hat is _not_ adding features to
it, let alone RHEL 4 (2.6.9) is just like SLES 9 (2.6.5), there are
hardware feature support issues.
This is about marketshare. Enterprises use YUM with RHEL 4, and
even 3 and 2.1 (although 2.1 support, with the native Python stack,
is very old -- unless you built your own Python stack). I haven't
run into an enterprise yet that didn't run YUM for RHEL 3+.
Even those that have RHN Satellite Server do. Spacewalk (upstream
RHN Satellite Server) makes things even more interesting because
there is backported support into YUM for Spacewalk. But that's
an even other story.
I warned about this before. I think the OpenSuSE move should have
been a "notice" to people like yourself several _years_ ago. Why
you're ignoring them is beyond me. That should be the best example
of "buy-in" I've ever seen!
> "Gaining traction" is not necessarily defined as "starting to
> get going right now".
Dude, read-up! This is 2009. YUM v3 came out and was adopted
three (3) years ago. I haven't heard a single complaint on YUM
that applies to YUM v3, and most people with YUM v2.4+ from over
5 years ago had few.
I think the SQLite support in YUM v3 really changed everyone,
including Novell-SuSE.
> I'm glad YUM is there, I just don't think it warrants an
> objective.
So LPI is going to continue to push APT but not YUM? We're going
to ignore the entire world that doesn't use RPM any more than they
use DPKG? What gives?
> And that's more due to resulting exam bloat and similar competing
> products that anything to do with it's technical quality.
YUM meta is now the defacto, universal standard in virtually every
RPM distro. Com'mon, even the OpenSuSE guys made it their exclusive
tree meta!
> So where do we stop, where is the line that prevents exam bloat?
I'd say over 35% marketshare (and that was last year) in business
usage is a good example, according CIO and IDC. ;)
*NO*ONE* administers with RPM when they have YUM. That's been the
case not only for nearly 5 years with many distros (including CentOS
rebuilds), but with Red Hat itself -- under full SLA for RHN --
for several now.
Why would you use RPM? For the most part, for only the same reasons
you have to "drop down" to DPKG on Debian/Ubuntu systems from APT.
To ignore YUM, especially given SuSE adoption, is beyond me. OpenSuSE
doesn't even offer anything _but_ YUM meta in their build tree.
> 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
Dude, DPKG is _still_ used! It is the "back-end" for APT-DPKG
on Debian, Ubuntu, etc... (have you even administered such?).
> while running rpm was still common.
To be a broken record ...
*NO*ONE* administers with RPM when YUM is available. *NO*ONE*.
In fact, even back in 2004, when someone would type "rpm -ihv"
I'd have to say ...
"What are you doing?"
"That's how you install a local RPM, I can't use YUM"
"What?"
"YUM is only used for installing from YUM repositories"
"Get out of the way" (and I'd type "yum localinstall")
The same goes for dependency trees, provides, info, etc... Why?
> But that's splitting hairs, let's look at what exists in the
> real world.
That's what I'm trying to smack into you! Dude, where have you
been?
OpenSuSE only provides YUM meta. YaST added it. Red Hat even
added YUM meta support to RHN tools shortly after the Fedora Project
was formally taken over by Red Hat employees.
> 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).
Dude, have you seen the CIO and IDC studies on Linux marketshare in
Enterprises? YUM based distros have _over_ a 35% share, which is
_more_ than APT-based distros. I don't know how much more I can
point this out.
I'm not even looking at the 3rd party repos either. Some provide
APT[-RPM] and SmartPM, but _everyone_ provides YUM.
If anything, multilib (multiarch) and other features in YUM[-RPM]
pre-dated virtually all other, community tools. Only SuSE's YaST
had multilib, which didn't have the same community usage.
Marketshare. YUM solved the problems first and best.
> OTOH, conceptual knowledge of what rpm is doing under the covers
> is important,
As DPKG!
> if only to know how dependencies tie together and how to
> interpret package manager errors. Knowledge of the tool itself
> is not *that* important.
Then why aren't we only testing DPKG then as well?
> Is that directed at me? or to the unwashed masses in general?
Dude, it's anyone who wants a job doing administration of any
RPM-based distro these days. I would say the same of anyone who
talks of Debian or Ubuntu and only knows DPKG.
Even for SLES, there's too much from the OpenSuSE community that
is going to be YUM. I honestly don't know how you could not see that.
> Well, as I said above, I never said or thought what this paragraph
> conveys.
Enterprises have been using YUM heavily for over three (3) years.
YUM meta became the defacto standard for anything RPM way back then.
Again, OpenSuSE should have been the "wake up call" for most.
-- Bryan
P.S. If Red Hat _and_ Novell are using YUM-based tools for all
of their development and redistribution, and have been for over
5 and 3 years, respectively, why doesn't this make sense?
Seriously! ;)
--
Bryan J Smith Professional, Technical Annoyance
[email protected] http://www.linkedin.com/in/bjsmith
--------------------------------------------------------
I don't have a "favorite Linux distro." I use, develop
and support community efforts, often built around Linux.
Technology and solutions are my focus, not dragging in
assumptions, marketing and other concepts which dominate
non-community developed software, which I left long ago.
_______________________________________________
lpi-examdev mailing list
[email protected]
http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
