Johnny Hughes mailing-lists@hughesjr.com wrote:
OK ... There have been some good suggestions on this thread
...
- 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.
- 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.
- 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.