Tomas ?gren wrote: > On 22 April, 2006 - Dave Miner sent me these 0,4K bytes: > >> Casper.Dik at Sun.COM wrote: >> ... >>> Since I feel package installation is a rare event, we really need to >>> optimize for the standard operations and not the install/upgrade. >>> The latter can be optimized in different ways. > > Just talking for myself, I'd say that I've used pkgchk to look for files > a handful times (if it takes 0.5 seconds or 1.5 seconds, I couldn't care > less).. Installing machines - many hundred times (not to talk about > patching which is a great pain too since it has the same slowness), and > while installing - pkgadd etc is run about a thousand times for a full > install... > >> Bingo. If you want fast installation, something like a flash archive >> seems likely to be the clear performance winner over anything you might >> do to optimize package operations. > > But flash archives are hard to manage.. You have to install a > system the way you want and then take a copy of it.. if you made some > error, you have to start the manual process all over again.. >
I agree that we need to make that easier to manage, that's part of the proposed strategy. Improving it will help solve several problems. > Why should there be a huge speed difference of unpacking one huge > archive (flash) compared to a bunch of small ones (regular packages) ? > They're doing just about the same thing in the end... > When it's one vs. 1700, there's going to be a substantial difference, because there is a lot of overhead to actually ensuring that package operations are correct (the semantics of the packaging system demand we do certain things, in certain orders), whereas just dropping an archive that's pre-built skips all that. > If the bottom line is 'many files' vs 'one file', why not have both? > During install/patching, tell pkgadd to do 'many files' to avoid > rewriting the entire file a thousand times and when the install is over > you (install program) can merge it back to the old contents files.. For > single pkgadds, rewriting it isn't nice, but multiplied by 1000 it will > take a significant amount of time.. > We can invent all sorts of "special" behaviors, but the problem is that they make the packaging tools more complicated, which will often have the perverse effect of slowing them down in addition to increasing support costs, and they don't necessarily solve any other problems. Sun's generally in the business of trying to do work which can be leveraged to solve multiple problems, so forgive me if I'm a little biased against that specific approach. I'm not at all opposed to speeding up the packaging operations, but I don't think it's the surest path to maximizing installation performance. Dave
