On Fri, Jun 05, 2009 at 12:18:57AM -0500, Shawn Walker wrote:
> Dave Miner wrote:
> >Shawn Walker wrote:
> >>This is not advisable. IPS needs to be aware of the files on the
> >>system so that it can effectively manage the system. If you start
> >>laying bits down in arbitrary places, then when packaging operations
> >>are performed, those bits may be deleted, moved to another location, etc.
> >>
> >>If the issue is with the difficulty in creating packages, the correct
> >>answer is to improve the publication process.
> >>
> >>Note this only applies if you're talking about OpenSolaris-based
> >>images that use IPS, etc.
> >
> >Reality is that users will have layered software beyond the OS that will
> >be in those other formats, no matter how easy IPS publication might be.
> > Denying the capability to include those in an automated deployment
> >product won't work.
+1
> The package management system cannot adequately manage or account for
> bits it doesn't know about.
Not quite true: IPS can at least know that there's something there that
would be overwritten by an IPS pkg, and that that something was not
installed by IPS. The latter fact is irrelevant -- there's a conflict
and the user has to know. Of course, expecting IPS to treat such
conflicts as error conditions is... perhaps unrealistic given that IPS
can't know about the conflicts at plan creation time unless it actively
scans the filesystem for unaccounted for objects.
Also, SVR4 packaging is supported on OpenSolaris, no? Shouldn't that
mean that IPS needs to be aware of SVR4 packaging contents when creating
install plans?? Surely sucking in /var/sadm/contents as best IPS can
would be feasible. Or perhaps SVR4 package installation should always
entail first converting the pkg and sending the pkg to a local IPS
repository to be installed from (though that gets us into automatic SVR4
package scripting migration; thankfully we've shown that that's feasible
for CAS and post* scripts).
> If the user wants to deliver files to a location that is not managed by
> the package system, that's fine.
Where would that be, besides, perhaps, the user's home directory? And
if it's anywhere other than /opt and /usr then whatever pkgs the user's
installing had better be relocatable (thankfully SVR4 packaging supports
that well enough). Or, if it's /opt then maybe conflicts will be
trivially avoided by the user anyways because of the way the namespace
under /opt is "managed".
> Anything else likely needs to be delivered as a package. Otherwise,
^
did you leave out "IPS"?
:)
> behaviour cannot be guaranteed.
