[23682] in Athena Bugs
Re: Delaying an update and keeping rpms
daemon@ATHENA.MIT.EDU (Tom Cavin)
Tue Aug 19 22:12:13 2003
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16194.38181.789327.292247@lap1-wccf.mit.edu>
Date: Tue, 19 Aug 2003 17:22:45 -0400
From: Tom Cavin <cavin@MIT.EDU>
To: Greg Hudson <ghudson@mit.edu>
Cc: Tom Cavin <cavin@mit.edu>, Athena Bugs list <bugs@mit.edu>,
SIPB Linux Help <linux-help@mit.edu>
In-Reply-To: <1061324782.16712.235.camel@error-messages.mit.edu>
Hi Greg,
That sounds workable if all the changes made by an update are in the form
of RPMs. Is that currently the case?
And are all the RPMs in one central location? Or are they scattered around
in a few places?
Totally unsupported is perfectly reasonable, as long as I can ask the
occasional question. (I do realize that I'm not guaranteed answers. :-)
--Tom
Greg Hudson writes:
> The safe updates feature (the -c option to rpmupdate) insists on making
> its own fresh copies into the copy area, because otherwise it would have
> to worry about corrupt or truncated stuff living in the copy area.
>
> You may be able to do what you want by copying the new RPMs onto the
> target machine ("update_ws -n" will list all the changes made by a
> particular update without making any changes, but it won't give you
> filenames, unfortunately), hacking the release list file to point to the
> copied RPMs, and running rpmupdate on the hacked release list.
>
> Totally unsupported, of course.
>
