[CentOS] Why is yum not liked by some?

Fri Sep 9 20:22:46 UTC 2005
Les Mikesell <lesmikesell at gmail.com>

On Fri, 2005-09-09 at 14:41, Bryan J. Smith wrote:
> Les Mikesell <lesmikesell at gmail.com> wrote:
> > it would be trivial for a client to decide whether it is
> > more efficient to apply a delta to an existing cached or
> > locally available version or pull the latest.
> 
> But how does the "appropriate delta" get built?
> At the server!  That's more server overhead, let alone the
> "service" that the client uses to query.

It would be built by the person who maintains the master
repository - only once per new RPM rev.

> Now let's say you just have the client download the _entire_
> delta for the RPM to avoid all that extra server overhead. 
> Now you're actually _increasing_ the amount you download. 

Huh?  You don't build the delta on demand, you offer a choice
of full revs and deltas and their sizes.  The client can
easily compute which to download based on what it already
has.

> > Likewise, how does the style used in rdiff-backup compare?
> 
> rdiff-backup does 1 delta, against 2 files.

Yes, that would be the way to do it.  As a final step of
creating an RPM update, build that delta.   Offer it to
the millions of clients who already have the original
file.  It would be a nice proof-of-concept to feed the
updates at the end of a fedora cycle to it to see what
the savings would be to use deltas vs full downloads.

> rsync does *1* delta.
> Furthermore, it's not as efficient as a straight HTTP stream
> when it comes to the server.

> > With rdiff the server side work only has to be done once.
> 
> Not for rippling through multiple deltas, which is what
> versioned files are.  Several of you seem to forget that
> aspect.

The delta between any version and its next update will
never change.  Make it once, store it, mirror it, whatever.
Do it again separately for the next version (delta from
it's immediately prior version only).  Leave it
up to the client to figure out what it has to start with
and whether it is cheaper to apply a series of deltas
or pull the full copy of the version it wants.

> You're talking a lot more overhead than just a HTTP access.

No, just one extra, probably automated step in adding a new
update version that only gets done once.

> But what do clients need?  Re-assembly in the check-out!  So
> if there have been 5 version updates since, then _all_5_
> deltas will need to be "rippled through."

Done on the client side - and only after computing that the
operation is cheaper than jumping directly to the desired
version.

> So why not just store the _whole_ versions?
> That's my point.

You should.  Just give the client the choice.

> > You would trade that off against the
> > network traffic saved when the client chooses the smaller
> > delta.  But, for this to work you need an on-line local
> > cache of the base rpms.
> 
> Hence why you should have a local repository!
> Isn't that what you were arguing against?!?!?!

I'm not against having local repositories. I'm against anything
that takes human time/intervention.  Put a price tag on it
and you'll see why.  I have no problem tossing a few hundred
gigs of disk space out if no one has to manually edit anything
anywhere to use it.  If my install procedure starts by copying
the base rpms somewhere or the NFS-shared directory where
the downloaded isos were specified during the install is saved
it would be fine with me.

-- 
  Les Mikesell
    lesmikesell at gmail.com