Philip Brown wrote: > Bart Smaalders wrote: >> ... >> Today, a "conformant" postinstall script may only invoke utilities >> present in >> whatever the minimum supported cluster was in the oldest OS from which >> those diskless clients could be run... many scripts out there today >> blithely invoke binaries >> that are part of the package being installed. This doesn't work if the >> image being operated on w/ -R isn't the same architecture or patch level >> as the running image. > > > Interesting. But in a way, this is "non-supported" behaviour. I dont recall > ever reading anything about this sort of issue in the packaging guide. > Sounds like you are looking to enhance capabilities beyond current > standards. Which is a fairly good thing. ..... >
Please read the following: Solaris Live Upgrade Inactive Boot Environment Compliance -------------------------------------------------------------------------------------------- http://docs.sun.com/app/docs/doc/817-5768/6ml70g62k?a=view > > You could choose to do this, without requiring tweaking existing > "postinstall" behaviour, though. > > Phil, the system is completely different. To insist that the new packaging system be bug for bug compatible with the vast assemblage of hacks that comprise the current system is absurd. Should we continue to support calling installf in a postinstall script? oh wait a minute, that means that we need to continue to support class action scripts, too. Is grepping through the contents file still supported, too? We're blowing that cruft away. If you want to continue to use sv4r packages, we're still shipping all the old cruft. We're just not going to use it for the OS, because it's inadequate to the task at hand. >> By confining install-time actions to a known set (mostly done in python) >> and delaying others until the image being manipulated is running as part of >> the >> design, we can avoid most of these issues. > [becauase "those issues" are fixed, by delayed "invoke other actions on > target system using SMF" strategies] > > Well, that's ONE way to handle those problem. > There are other ways, however. > > First, I'd like to mention my own personal views on packaging systems. > As previously mentioned, I think that a package maintainer's 'job', should > be to transfer as much of the hassle from the user, to themselves. > Similarly, i think that the 'job' of a good packaging system, is to transfer > as much of the hassle from the package maintainer, to ITself. > In other words, whenever possible, to make it *easier* to package something, > rather than harder. > IPS will make packaging software very easy. It doesn't support Java code refactoring, database version conversion or interrogating the user as to the desired IP address of his new NIC. It will have a defined series of behaviors, including a way of specifying software to run in the image context once installation has completed. > Now, a view on "other ways" to approach the postinstall issue: > > > As an example, I would like to reference how postinstall scripts are > handled, *right now*, with solaris 10 and zones. > For those zones that inherit the pkg through pkg-inherit-dir, that zone is > automatically booted into "administrative state", if it is not currently > active. So if I upgrade a package on 100 zones, I need to boot, update and shutdown 100 different zones, and rewrite 100 different contents files. > The postinstall script is then run "in the zone". Normally. No special > tweaking, or "zone awareness" needed. The packager did not have to do any > backflips to support zones, unless his postinstall script was ludicrously > messy. > Or it combined root and user binaries together, ran any binaries from his own pkg, etc.... > Similarly.. you COULD choose, to support postinstall scripts transparently. > By automatically wrapping them in whatever SMF/zone/etc magic is appropriate > for the target environment, and scheduling it to start whenever appropriate. No, because many of those scripts call svr4 packaging functions, such as installf. They're simply not compatible in the general case, and trying to pretend that they are the same is bound to fail. > Something to think about: > With blastwave packages, we obviously dont "have" to use SMF-style init > methods. We could just package up everything with the old rc.d style. > However, with most of our newer packages... our maintainers CHOOSE to put in > the extra effort, to take advantage of the new SMF stuff, when it is > available. > You can continue to use sv4r packages if you wish. If you want to use IPS, and you need something to happen besides getting your bits laid down, services defined, users created, etc, you'll need to to write some routines to fit into the new framework. > > here's something else for you to chew on: > > If YOU dont make it easy to transition or incorporate postinstall scripts, > to your new SMF style, in an easy automated painless way... SOMEONE probably > eventually will write a toolkit to do it in a more ugly, but USEFUL TO > DEVELOPERS, way. > > So... would you rather see that happening in some future unknown way? or > will you choose to incorporate it into the IPS design up front? Most of the reasons to create post install scripts are going away completely with IPS. The ones that remain would likely not work anyway, so they will need rewriting. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird". _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
