Jordan,
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?
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.
2) Often, the person doesn't want the application to run with root
permission
3) Multiple versions of the application may need to run on a single
system (differing at any release level, not just major releases)
4) The application may be intended for only a single user, e.g., a web
server running only in a webservd account.
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).
Note that SMF, drivers, rebooting the operating system, installing into
offline zones, etc. do not come into play at all with this scenario
because the non-root user doesn't have the necessary permissions.
The question of configuration associated with updates to the existing
software does still come into play. Maybe we need some sort of service
action for user images (that doesn't depend on SMF). As an initial
(possibly temporary) solution, the Update Center [1] updatetool (a GUI
interface for IPS that is intended for applications across various
platforms, not just OpenSolaris) looks for a set actions in the packages
for scripts to run after installation or update is complete (see [2]).
We've started developing some IPS packaging best practices for
applications using Update Center (see [3]) and these talk about 6
available methods for doing configuration of the application. The
postinstall script is one of the last choices.
[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
Tom
Jordan Brown wrote:
Trevor Watson wrote:
If that can be reasonably detected, yes, it should be reported as a
failure.
It will be reported as a failure - most likely your system/container
will fail to boot or will panic at some point. I count that as a failure
report :)
That sounds a great deal less user-friendly than the equivalent errors
that I might get from rpm or pkgadd.
It's all part of "get me my darned application so that I can do the
work that I really want to do".
I think you are mixing up contexts here: applications vs services or
system bits.
To some extent, yes. *Mostly*, I don't think there's a big difference.
However, my personal perspective at the moment is as an application
provider; how the OS gets installed is of no interest to me (when
wearing my current hat).
In the case of an application - if it needs specific (ie not generic
actions such as update GNOME menus/cache/etc) configuration in order to
get it to work, then you could either write your own installer for it
I thought one of the goals was to eliminate custom installers.
or create an SMF service which automagically creates a default
configuration in a one-off run.
... which means that failures are reported poorly.
For system type things, IPS delivers the bits, some actions get fired
off to do the necessary install and that's it. If it fails after that,
then that is not an IPS problem (unless, of course, it is a bug in IPS).
If you constrain IPS's scope, sure. That's the question.
There are classes of failures that will be clearly and cleanly reported
by pkgadd and rpm, what will be reported quite poorly in an IPS world.
I think Shawn perhaps over-stated the bit about IPS knowing that a
service won't start or maybe I'm missing something. Certainly in the
case where a package is being installed in an not-running zone, then IPS
cannot reasonably know that any particular service will not start on
boot, but when the zone comes up, svcs -x should give some indication
(in theory).
Sometimes it can.
If it wasn't able to add an entry to a table (and here I'm not
immediately coming up with the combination of (a) something that needs
an entry added to a table and (b) has clear failure cases and (c) is
applicable to a zone, but with research I'm confident I could find a
case), then that's a failure that pkgadd or rpm would immediately
report, that IPS (as it seems to be scoped) would defer to zone-boot and
report in an obscure log file.
You keep saying "software management subsystem" which to me implies
something more than just package management.
Perhaps. I thought it was all package management, but the local
terminology here seems to have constrained "package management" to
little more than laying down the files, so I had to come up with a
broader term that covered the entire soup-to-nuts process.
Anyway, I don't think this thread is going anywhere, so this will be my
one and only contribution to it.
That's my fear too. I suspect that the result will be that it will be
clarified that IPS's scope is quite limited, in some areas significantly
more constrained than pkgadd or rpm. Wearing my application provider
hat, I'll work around that, probably by writing my own installer.
Wearing my technologist hat, I'll be disappointed.
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
