<br><br>
<div><span class="gmail_quote">On 11/8/05, <b class="gmail_sendername">Frank Wiles</b> <<a href="mailto:frank@wiles.org">frank@wiles.org</a>> wrote:</span></div>
<div><span class="gmail_quote">></span>You're talking about the --repackage option. This essentially</div>
<div>. . .</div>
<div>>save a rollback on all installs/updates, however I found that it<br>>double ( if not tripled ) the time it took to do updates.<br> </div>
<div>That's to be expected. First the installer has to open up the package to see what's in it, so that it can generate the list of things to back up, then go back and actually do the install. 3x sounds about right.</div>
<div> </div>
<div>I've given this some thought because I've done some work on protocols for packaging updates to my company's software. I wrote a quick-n-dirty utility that peeks into one or more tarballs (the main format our updates are packaged in), backs up the files about to be replaced, and then unpacks the tarballs. As an added bonus it logs the version numbers on all the binaries involved both before and after update, so you can confirm that you've got everything done.
</div>
<div> </div>
<div>They used to have to do this by hand. The software installation team (who have to install the point release off CD, and then put in the updates that have come out since the release) loves it. Imagine how they'd like a real package manager like RPM or apt!
</div>