Re: Why is yum not liked by some? -- CVS analogy (and why you're not getting it)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



Johnny Hughes <mailing-lists@xxxxxxxxxxxx> wrote:
> OK ... There have been some good suggestions on this thread
...
> 1.  It might be good if you could pass a date as a command
> line option to yum ... and have yum not consider anything
> after that date as being in the repo.

I don't think anyone disagrees with that.  The problem is
that the current format of meta-data in the YUM repository
makes this difficult -- let alone how do you "define" the
date?

I suggested a simple "hack" on the repository end that merely
retains previous createrepo runs.  That way you can go back
to any previous "state" of the meta-data that someone else
might have pulled from earlier.
 
> That is a good suggestion for the yum mailing list:
> https://lists.linux.duke.edu/mailman/listinfo/yum

I will join and offer my simple "hack" as a suggestion for
handling the repo end until a more formal concept can be
devised.

> 2.  It might be good to develop a way to distribute update
> RPMS with only the changed (delta) information and not all
> the information, thus saving time and bandwidth and storage

> space.

For mirrors, it _might_ be a good way, I don't disagree.  As
long as only "a few" mirrors are yanking files.  That will
minimize the load of the ripple delta processing.

But for connecting dozens of clients, especially over the
Internet, I think the space savings is going to be off-set by
the massive overhead.

E.g., In most configuration management systems where TBs of
binary data are involved, I've found the systems are
intolerable after just after a few clients.  In fact, what I
typically do is have only the delta process run on the local
disk, and then share out the resulting "assembly" via NFS.

So it would work as long as only a few clients connect --
such as limiting to mirrors.  But when it comes to client
operations, the load and temporary space used will not only
be self-defeating, but far worse than just a flat/whole
repository.

> This is also a good suggestion, but not really for CentOS
> ... we use up2date and/or yum ...
> but if Red Hat where to change their method of distributing
> updates, then CentOS might too.  This suggestion also
really
> belongs upstream (if it is going to be acted upon).

Agreed.

> 3. It might be good to have a method for deploying
> different sets of packages to different machines and
control
> them individually or as a group.  The program "current" is
> working on doing that:  http://current.tigris.org/

Yep.  There's a lot of capability that Subversions and other
version control systems are offering.

But there are -- how can I say this -- "real world
deployment" and "server v. client v. bandwidth load/transfer"
issues.  For each solution offered that fixes one problem,
several others seem to be introduced.

I don't think anyone is arguing these things are not wanted
-- God knows I'd _love_ to have these capabilities.  But
their feasibility is entirely another issue, and it requires
some first-hand experience with how YUM repositories work, as
well as binary delta'ing loads and buffering/temporary space
when links are slow.

Running an rsync or two between a few systems is somewhat of
a load.  But doing a compounding set of rysncs (which is
basically what delta'ing is) to numerous systems is going to
introduce a load on the service that is far removed from just
HTTP file services.  ;->

> Please ... let's offer constructive and non attacking
> comments to this and all other threads on the mailing
lists.

I think that's all I'm trying to do.  But I will admit I did
get a bit "frustrated" when people assumed how something
worked, and it didn't.




-- 
Bryan J. Smith                | Sent from Yahoo Mail
mailto:b.j.smith@xxxxxxxx     |  (please excuse any
http://thebs413.blogspot.com/ |   missing headers)

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux