On Tue, 2005-09-13 at 21:21 -0500, Les Mikesell wrote:
[snip]
> Yum does its dependency computations on the client side
> based on the contents of the .hdr files (otherwise
> it wouldn't work when combining the contents of different
> repositories). It needs the .hdr files, not the RPMS.
> There is some magic in the repo metadata that makes
> the client only download the latest .hdr files but if
> you update often you end up with them all anyway and
> use only the latest. The needed change is that if you
> specify a point-in-time the client should toss/ignore
> .hdr files past that and get downrevs if available. Note
> that you could do this yourself with nothing but an
> ftp view of the repository and you'll see the client could
> do it directly, although I agree that repository support
> could make it easier.
Yum doesn't do it the same way anymore.
The old way (a bunch of header files ... one for each package in the
repo {yum upto 2.0.x}) has been replaced by a new way in yum > 2.1.x.
This new way is with files called repomd.xml and primary.xml.gz (yum
2.1.x and 2.2.x) or primary.xml.gz.sqlite (yum 2.3.x and 2.4.x). Old
header files are not really available.
Using the date added to the mirror is not good. A copy with the wrong
switches ... signing with a different key, etc. changes that (when the
package is actually the same). Not to mention that we maintain several
repos that get rebuilt at different times.
> I'd call it a minor change to expose an option to get
> backrev .hdr files when wanted.
>
It is a major change ... the entire repo is looked at as a whole at
rebuild time for the metadata, not as 10,000 packages but as one entity.
Because of this fact (as Bryan has pointed out), you would need to keep
older entire repo snapshots of the metadata to use to resolve your
dependencies separately.
The more I look at this problem, the more I see that a local repo
maintained by the local user is the right answer. It works right now,
requires no changes, and let's you control EXACTLY what you want in your
repo (including files from other places in a single repo).
You can freeze package xxxxx and it dependencies as you see fit, and add
only tested packages to the repo. It is just the right way to do
version control if you don't want to just use the version control that
is published by the repo maintainer.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.centos.org/pipermail/centos/attachments/20050914/af2bef65/attachment.bin
