Les Mikesell <lesmikesell at gmail.com> wrote: > No, that's what I want to avoid. Everyone else responding > *is* maintaining snapshot copies of repositories and I > don't think anyone should have to. Yum's view of a > repository consists of all the hdr files it has downloaded > from it. Yes, for a _specific_ set of RPMs. That is pre-generated, and available statically for the current RPM set. YUM repositories cannot say ... "oh, what if this RPM wasn't uploaded?" and that type of arbitrary meta-data. To do so requires multiple copies of the meta-data. > I want it to pretend that files added after > a certain time weren't there, thus creating a view of > the state of the repository at a prior time. Then you need a _different_ meta-data snapshot from that _earlier_ time. Either that, or a delta of _all_ headers, which significantly _bloats_ the meta-data. Which means the client either has to download _all_ that meta-data history, and do its own delta-assembly/resolution, which means a _lot_ of traffic. *OR* the server has to have a dynamic service that does this for a client. In _either_ case, the initial delay when yum is run and the meta-data is fetched/resolved is massive increased. You go from seconds to minutes. > Given only that, nothing anyone has said yet has convinced > me that that yum would not make the same decisions > about update versions again. Understand YUM is making update decisions based on the meta-data provided by the repository, and that meta-data is for the _current_ state of the repository. There is absolutely _no_way_ that meta-data it can provide "here was the state of the repository 5 minutes ago" or "10 hours ago" or "when another system ran 5 days ago." A YUM repository is a web site with RPMs. It has a meta-data listing for YUM clients. YUM clients do _not_ read the RPMs/headers. They only read the meta-data. That meta-data is pre-built, against the repository. It cannot tell the YUM clients anything about the state of the repository at an earlier date. To do so would either require a massive bloat of the size of the meta-data, or a dynamic service at the repository (instead of simple HTTP serving) to generate that information. An alternative is to use my prposed "hack" that lets YUM clients retrieve any prior, pre-built meta-data list. That way anytime the meta-data is regenerated, old meta-data lists are not lost and still available. But it requires a modification on the repo side. The meta-data does not and cannot (without _major_ changes) support any "history." That's what you're not seeing. And it falls on your usage of YUM only as a client, and not any experience of creating a YUM repository. It's a web site with an index (the meta-data) -- nothing more! In fact, it's like the difference between an Apache server, and Subversions using Apache+WebDAV+DeltaV (WebDAV adds file management, DeltaV adds basic versioning). -- Bryan J. Smith | Sent from Yahoo Mail mailto:b.j.smith at ieee.org | (please excuse any http://thebs413.blogspot.com/ | missing headers)