Tom Mueller (pkg-discuss) wrote: > Can you be more specific about what you mean by "application" when you > say that you are coming from a perspective of an application provider?
My particular application is a system management framework, xVM Ops Center. I am not quite sure how much has been publicly revealed so I need to be a little cagey, but it has a few install scenarios: - Human-attended server and proxy installations on running systems. - Automatic remote agent installations on running systems via ssh. - Automatic agent installations as part of OS installation and first boot (currently done during first boot). - Factory installations of the entire stack. A key factor is that none of these _require_ alternate-root installation. Another key factor is that for most of the cases there is a user interface running that should present any failure reports. Our application is supported on Solaris and Linux. The agent stack is required to work on Solaris 8 through 10 and several Linux variants, and the server and proxy stacks are required to work on Solaris 10 and RHEL5. There are looming support requirements for S11/Nevada/Indiana. > There are several characteristics that come to mind for applications: > > 1) Often, the person installing the application doesn't have root > permission on the system. Does not apply to us. > 2) Often, the person doesn't want the application to run with root > permission Does not apply to us. > 3) Multiple versions of the application may need to run on a single > system (differing at any release level, not just major releases) Would be nice but is not currently a requirement for us. > 4) The application may be intended for only a single user, e.g., a web > server running only in a webservd account. Some of our stuff runs as private users (of which we have two or three), while some of it runs as root. > User images in IPS are intended to deal with these characteristics. > Packages can be pre-installed into a user image, and the pre-installed > user image can then be delivered to the system by an installer. Once > installed, IPS is used to maintain the software within the image. The > installer can deal with initial configuration using whatever means > necessary (independent of the packaging system). When our (non-interactive) installer completes, the next step is to take your web browser to our BUI, so when the installer completes there needs to be quite a substantial amount of code fully up and running. We could indeed have an installer external to the packaging subsystem, and at the moment we do have such an installer. We regard that as a deficiency and have been working to eliminate it in favor of putting all required installation and non-system-specific configuration into packages, primarily for modularity reasons. I was under the impression that one of the goals of IPS was to eliminate the need for external installers. > [1] http://wiki.updatecenter.java.net/ > [2] http://wiki.updatecenter.java.net/Wiki.jsp?page=UC20FSD.InstallConfig > [3] http://wiki.updatecenter.java.net/Wiki.jsp?page=UC20.Docs.Packaging Very interesting. If it's made flexible enough, that could address many of my IPS concerns. IPS would become an underlying layer that humans should never touch, like cpio is for pkgadd. _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
