Nicolas Williams wrote: > On Wed, Feb 07, 2007 at 01:48:57PM -0800, lianep at eng.sun.com wrote: >> David Bustos writes: >>> Quoth lianep at eng.sun.com on Tue, Feb 06, 2007 at 05:50:11PM -0800: >>>> Delete use cases: >>>> [...] >>>> >>>> Upgrade use cases: >>>> - pkgrm/pkgadd combination for packages that don't support upgrade >>>> in-place. Users' customizations on the service should be >>>> preserved. >>> Aren't these contradictory? During the pkgrm, how can we tell whether >>> we're supposed to remove customizations or leave them? I believe the >>> packaging system assumes customizations are in editable files and just >>> leaves them after a pkgrm, in anticipation of a pkgadd. We don't do >>> that in the repository today, but we could with Enhanced Profiles. >> I tried to articulate the behaviour that folks seem to expect, and was >> concerned about the contradictory-ness of those expectations when I >> wrote it. In other words, thanks for the catch. :) >> >> Perhaps the requirement could be written to say that user customizations >> are preserved, and users need an explicit way to revert to an >> as-shipped configuration? > > Ugh. > > It'd be so much nicer if packages just supported instance update and > pkgadd made it easier to use that. The package framework for it is > already mostly in place. Then pkgrm could mean "delete this, including > customizations" and pkgadd could mean "add or update, preserving > customizations." > > But though the pkg system does support a notion of pkg updates, it does > so poorly and we don't use it, so we're stuck with pkgrm + pkgadd for > updates. > > So the question becomes: how do we distinguish between "forget > customizations" and "keep customizations"? > > I.e., what interface do we provide by which the user can make this > distinction? > > A pkgadd response option could do it, but that's hard to use. And it > doesn't give the user a way to uninstall a package such that no traces > are left of it. But as long as update -> pkgrm + pkgadd then we'll need > a pkgadd-time option. > > This strikes me as an issue that goes well beyond SMF. > > Nico
Yet another reason why we need a new packaging system. - Bart -- Bart Smaalders Solaris Kernel Performance barts at cyber.eng.sun.com http://blogs.sun.com/barts
