Nicolas Williams writes: > 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.
Yes and no. :) We need to agree on a sensible default regardless of new interfaces available. Unfortunately, I think that sensible default is preservation of user customization across pkgrm/pkgadd; as you mentioned, full use of the upgrade ability of packaging isn't widespread. Also, preservation of customization is similar to what folks have come to expect from other packages which deliver editable or preserved files. If we agree on that as a sensible default, we're free to offer an SMF-specific interface to revert to the delivered configuration. (It'd be generic across all services.) I'd like to complete the statement of requirements, so that we can evaluate the combination of proposals that are coming down the pipe against how they satisfy these requirements. Thus, I'm trying really hard to avoid suggesting solutions along with the requirements. :) (It took me a while to cut all the proposed solutions that slipped in along the way out of my original mail.) liane -- Liane Praza, Solaris Kernel Development liane.praza at sun.com - http://blogs.sun.com/lianep
