Les Mikesell lesmikesell@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).