chasd wrote:
Getting a bit off the original topic here, but the "other" thing I've
always wished yum could do is "repeatable" updates. That is, the
ability to update one machine, test some things, then update another and
get only the same set of changes even if some newer packages had been
subsequently added to the repos.
To me, that isn't functionality for the client, it is functionality for
the server / cache.
It is a feature of WSUS - the ability to approve updates and only allow
clients to "see" the approved ones and not any other.
Right now, there isn't a lot of intelligence built into the server end (
MirrorManager excepted ) of the update process. The repositories serve
static files, that's it. Fedora can't ask any more from mirrors. If in
your environment you want to control how clients get updated, then it
makes sense to me that centralized control from the server side and
keeping the client side "dumb" is better. You only have to distribute
the repo configuration to use the controlled repo once, instead of
distributing specific update lists continually.
That control is one of the reasons why as an admin I am interested in
InstantMirror and this discussion.
I was thinking that if the client were aware of all the packages in the
repo, all you'd need is a timestamp or some sort of transaction id
associating the last rebuild of repo data with the packages added then.
That way you could tell the client the timestamp or latest id that you
wanted it to duplicate, and it could just ignore any packages newer than
that. I think the client normally only sees repo data for the latest
version of each package that is available - but there must be some way
to get the dependency info for older ones, given the ability to request
them specifically.
--
Les Mikesell
lesmikesell@xxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
