Volker A. Brandt wrote [06/08/2008 08:39]: > Hello Stephen & Bill & List! > > It's great to see some real-life examples going through this list. > Ideally, it would be very instructive if Bill could post some > "before - after" comparisons once he has converted his packages. >
I'd be happy to do that, as and when I get to that point. At present I'm just trying to assess how much time it is likely to take to do the migration, and the result of that will determine when (or indeed whether) we go ahead and do it. That is very much an open question at the moment: I already have pkgadd and RPM versions of the package to maintain, and I'm going to take some convincing that what I really really want is to add a third version to that list. >>> - check for a couple of prerequisite user accounts: abort install if >>> they are not found >>> >> Use user action to install user accounts; fails if privileges are >> insufficient or accounts don't exist. >> > Maybe I misunderstand, but I think the original intention was to fail > without creating a given account if it did not exist. That nut is a > little harder. :-) > The "original intention" is not entirely fixed. The existing pkgadd and RPM implementations of my package check for the existence of a couple of required user accounts, and abort if they are not found. That logic lives in preinstall (for pkgadd) and %pre (for RPM). The same behaviour would be acceptable in an IPS implementation, but a better alternative would be to actually create the user accounts and carry on, rather than aborting. (Technically I could have done that in pkgadd/RPM, but it seemed a bit scary ...) >> We don't have support for smf(5) service suspension yet, but we will. >> Maybe I shouldn't have used the term "service". The package in question isn't a service, in the sense used by SMF; maybe it should be, but that's another change of functionality which we would need to assess. What I would really like is the ability for IPS to call an arbitrary command in the package itself. That would be useful both at upgrade time and at uninstall time. >> Please feel free to describe the other behaviours; we'd be happy to >> look at the postinstall as well--much of it can probably be absorbed >> into actions or action attributes. >> > I would very much like to see such a discussion. > I really don't want to get into a discussion of postinstall behaviour. My postinstall script is a 3000+ line shell script, which calls numerous other scripts and executables - all of which are specific to the functionality of the package itself. Even in the pkgadd/RPM implementations most of this is now decoupled from the actual package installation, and is attached instead to the first instance of the package's "start" command. -- Bill _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
