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"? ... > 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. David
