Les Mikesell <lesmikesell@xxxxxxxxx> 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@xxxxxxxx | (please excuse any
http://thebs413.blogspot.com/ | missing headers)
