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)
