Johnny Hughes <mailing-lists at hughesjr.com> 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 at ieee.org | (please excuse any http://thebs413.blogspot.com/ | missing headers)