Yum, Proxy Cache Safety, Storage Backend
Les Mikesell
lesmikesell at gmail.com
Fri Jan 25 02:23:47 UTC 2008
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 at gmail.com
More information about the devel
mailing list