David Bustos writes: > Quoth lianep at eng.sun.com on Tue, Feb 06, 2007 at 05:50:11PM -0800: > > Getting rid of the upgrade file is one of my long-standing goals. That's > > why it remains a private interface -- so that we can delete it once > > we've migrated current consumers over to a better interface. > > > > Why's it a bad interface? Because it's a dumping ground for shell > > commands. Only by virtue of the fact that it's a private interface > > have we kept it to be an SMF-only mechanism. I've fielded more than > > one request to put non-SMF shell commands in it. :( It's also > > opaque today -- it's very difficult to tell that a command in the > > upgrade script is why a property has been modified. > > > > My niggling concern is that an upgrade method is just moving all of the > > problems of the upgrade file to a new, public location. You've still > > got a dumping ground for shell commands which do opaque things to the > > system. But, on the other hand, at least they're attached to a > > specific service. > > Isn't the upgrade file a "dumping ground" because it contains commands > owned by multiple services? How can a script delivered by a service be > a "dumping ground"?
It's the "opaque things to the system" part that is retained across a refinement from a single file to individual files per service. But, as I said, since I don't have a better solution to propose, it's at best a niggling concern. > > ... > > Delete use cases: > > - Service is removed from alternate root & appropriate profiles. > > Either before or during next boot, service is deleted completely > > before it has a chance to start. User customizations on the service > > are removed. > > > > - Service is removed from running system & appropriate profiles. > > Service is deleted immediately, and any dependents not tolerant > > to failure are stopped. User customizations on the service > > are removed. > > > > 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? > We don't do > that in the repository today, but we could with Enhanced Profiles. As I mentioned before, I'm attempting to set requirements against which the solutions can be evaluated. I'm not making statements about what we do or don't do today, or applying specific technologies to meeting these requirements. (Yet.) liane -- Liane Praza, Solaris Kernel Development liane.praza at sun.com - http://blogs.sun.com/lianep
