Re: Why is yum not liked by some? -- CVS analogy (and why you're not getting it)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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)

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux