Re: APT v. YUM -- understanding the technology

["Bryan J. Smith" <b.j.smith@ieee.org>]

On Sun, 2004-11-21 at 17:43, mike808@users.sourceforge.net wrote:
> My bad. You are correct.

No problem.  It's easy to think of DPKG as APT, with RPM on its own.  In
fact, that was a major argument against Red Hat and other distributions
distribution, because Debian inherently used an "advanced front-end" to
its "back-end" package manager. 

But the reality is to notice that _all_ distros offer some "front-end"
mechanisms for updates, distributed dependency resolution, etc..., even
if most people (myself included) Debian's "community distribution" has
largely proven to be superior overall -- or at least the most mature.

> I guess the proof of my point is really the answer to this question:
> Why is there no "YUM for dpkg"?

Actually, that only raises more and other questions.

First off, APT works well for DPKG, and has for a long time.  There's no
sense in replacing it with something else, unless that replacement
offers a major advantage.  That doesn't mean YUM is "inferior," not at
all.  But APT does not seem to need replacement for DPKG.

Secondly, understand that UP2DATE works well for RPM too.  In fact,
UP2DATE is still at the heart of RHN distribution.  But Red Hat has
since modified it with _both_ APT and YUM support -- so RHN subscribers
can tap both their repositories, and then 3rd party repositories.  E.g.,
grab a package for RHEL from a 3rd party, but resolve any dependencies
against the RHN where appropriate.

Third, understand that other mechanisms work well for other distros
too.  Beyond Debian and Fedora project based distros that can tape those
respective projects, Mandrake, SuSE and others can resolve against their
own update services.  Additionally, they officially and unofficially
support other utilities and repositories.  There are people using APT
and creating APT repositories for Mandrake, even though Mandrake doesn't
support it.

Lastly, you don't "need" APT, UP2DATE or YUM for RPM anymore than you
"need" APT for DPKG.  You can manually download RPMs and DEBs and
install directly.  On that same point, because you are still installing
the actual RPM or DEB with the back-end, you can use the front-ends
interchangeably!  I.e., you can use _both_ APT and YUM (and even UP2DATE
too!) on a Fedora Core or RHEL system without issue.  Because the
"front-end" mechanism for "fetching/resolution" is still not the final
"back-end" where everything is actually done.

And this brings us to the Fedora project.  2 years after introducing Red
Hat Enterprise Linux (largely following SuSE's lead after poor
acceptance of Red Hat's "E" SLA offering -- e.g., Red Hat Linux 6.2"E"),
Red Hat had been evolving RHL into a non-competing solution.  One that
would better solve the community, and solve other, pressing issues (like
trademark -- of which, no other, major commercial Linux vendor let their
trademark go so overused in derivatives, not merely duplication). 
Fedora largely emulates Debian in one major area, community
distribution.

The new suite of changes and tools are now following.  So far, even
though the original Fedora Project (Fedora.US / Fedora Extras) preferred
APT, and continues to provide an "unified" APT repository of Fedora Core
(OS), Extras and Legacy, Red Hat seems dedicated to furthering YUM.  I
haven't really questioned it until recently, wondering what YUM offers
that APT does not.  And I still don't think it has been answered well.

> That's where the NIH fits in.

To rethink this, not totally.  Understand YUM is Yellow Dog Update
Manager.  It's not a Red Hat creation.  In fact, most 3rd party RHL
repositories before the Red Hat adoption of the Fedora Project used
largely APT, including Fedora.US itself.

I can only assume some former Yellow Dog people are now with Red Hat? 
Maybe they already have code modifications for the Anaconda installer? 
That could be a major reason as Red Hat is attempting to unify the whole
suite of tools, from the Anaconda installer to the Fedora Newt admin
applets around YUM.

[ Seth stated there are no less than 5 "package meta-lists" in the
current Fedora Core release -- not very unifying. ]

> RH doesn't directly benefit themselves, and put themselves in a
> "leadership position" on package management tools by choosing APT.
> In the APT world, APT4RPM is just another "me-too" APT implementation.
> In the YUM world, since RH invented RPMs, and YUM only supports RPMs,
> by picking YUM, that puts RH in the driver's seat on YUM development.

Er, yes and no.  I guess yes if a lot of former Yellow Dog people are
now at Red Hat, or there is some cross-development now.

But I also forget about Progeny's Compontentized Linux, which is Debian
(and soon?/now? Fedora) with the Anaconda installer adopted.  I wonder
if APT has been integrated?  I'm speaking from ignorance, of course.

> Which leads me back to why I asked why is there no "YUM for dpkg"?

Because it's not needed.  But I'm sure someone _could_ offer it.  But
also as I pointed out, you _can_ use _both_ APT and YUM on the same
system without issue.

> The answer is because RH has no interest in funding it,

Red Hat funds a lot.  They can only do so much.  Why fund YUM for DPKG
when APT is well established?  In reverse, remember that Debian did
_not_ fund development of APT-RPM, it was Connectiva.  So I fail to see
the reason for this statement?

> which will, I believe, make YUM a niche player -- by RH, for RH,

Actually, YUM is used by 3rd parties for other distros too.  As I
mentioned above, it's doesn't have to be APT v. YUM.  Both front-ends
can co-exist on a platform, and be used interchangeably.

> and as a result, really only useful to RH.

I differ.  If Red Hat can build an unified installer and set of admin
tools around YUM that work and work well, it might get used by not only
more 3rd parties for other distros, but maybe those other distros
themselves.

In any case, one _should_ recognize that Red Hat, _unlike_ most other
_commercial_ distributors, _is_ starting to recognize the _value_ of the
community distribution model.  Even if they fund the servers, networks
and have final say over the packages (Core), or legal issues (even on
Extras), the model is there.

It's really just the final evolution of what Red Hat started asking
themselves over 3 years ago with the introduction of RHEL, which finally
resulted many things over that time.  The Fedora trademark and name
change was just the end-game evolution a little over a year ago.  The
community distribution model was already in the works.

Heck, Red Hat was already turning its "for pay" RHN servers into "free"
UP2DATE servers _before_ Fedora was announced.

> I can point to GNOME as what I see as a similar set of circumstances.

Okay, now that's a stretch.  GNOME is _not_ just Red Hat.  Not at all.
In fact, there is a _lot_ of both community and commercial support
around GNOME these days, a major amount.

GNOME might have been started by largely Red Hat as a solution to _real_
licensing issues around Troll Tech Qt.  But this is a complete tangent
that I feel is well out of context in our discussion.

Just because Red Hat tends to be GNOME-centric in their distro, largely
because they _do_ fund a lot of GNOME developers (and openly admit
this), doesn't mean GNOME is Red Hat-only, or Red Hat is GNOME-only. 
Not at all.

> However, past performance is no indicator of future performance, as
> they say.

I'm still scratching my head on some of your comparisons when I feel the
context is no way applicable.

> This is shaping up to look like a case of free software competing in
> a free marketplace. In a BSD sort of way, it exemplifies the Darwinian
> notion of code evolution, in that good code survives.

I don't think YUM is necessarily "bad code."  But I _am_ waiting on
someone to tell me why YUM is "better."

Most of the statements have been either A) under the assumption that YUM
is somehow more "native" to RPM than APT (not true at all), or B) newer
YUM modifications/capabilities are not in APT (others have argued is not
true, I'm not sure).

The only other argument I've seen is the lack of having to run the
equivalent of an "apt-get update."  Frankly, I think this is not a curse
but a blessing.  I like doing things piecemeal.  If Red Hat really
doesn't like the fact that you have to do such when YUM does it every
time, then just alias any "apt-get" command as "apt-get update; apt-get"
and that is the same as the default operation as YUM.  ;->

> On the other hand, duopolies are tending to do very well right now in
> our institutional constructs. We have been shaping all sorts of things
> into duopoly controlled systems

And as I said, it doesn't have to be an APT v. YUM 'thang.  And I'm glad
to see that Fedora.US has _no_intention_ of discontinuing offering APT
or stopping its development for RPM.

> -- our US government being the prime example, but it goes all the way
> back to the primordial "good" vs. "evil". Obviously, whichever side
> _you_ pick is "good", and anyone choosing dis-similarly must therefore
> be "evil". But that's another discussion, best completed over two or
> ten beers. :=)

<politics>

Actually, I completely _disagree_.  Any role of government that attempts
to "provide for" the people only ends up being inefficient,
self-preserving and catering to special-interest.  

In fact, to people like myself, it's not the notion of "good" v. "evil"
but:
  "we will use your money better than you" versus
  "we will give to companies who will use your money better than us"
style of government.

But the the real "answer" to us is:
  "your dollar goes farther if we don't take it in the first place"
style of government.  ;->

Despite any thought that I'm registered "Independent" (sigh, I _hate_
that, call people by their _actual_ party affliation), I have been
indeed registered NPA (No Party Affliation) since age 18.

BTW, it was nice to see "the real John Kerry" once he conceded.  Sigh,
as George Washington believed, political parties are a bad idea.  Of
course, George Washington was a Federalist because most things don't get
done if you aren't so aligned.

Although I kinda like the idea of a "get nothing done" style of
government. ;->

</politics>

-- 
Bryan J. Smith                                    b.j.smith@ieee.org 
-------------------------------------------------------------------- 
Subtotal Cost of Ownership (SCO) for Windows being less than Linux
Total Cost of Ownership (TCO) assumes experts for the former, costly
retraining for the latter, omitted "software assurance" costs in 
compatible desktop OS/apps for the former, no free/legacy reuse for
latter, and no basic security, patch or downtime comparison at all.



-
To unsubscribe, send email to majordomo@silug.org with
"unsubscribe silug-discuss" in the body.