I've been handed a requirement, supposedly based on IPS requirements, that our packages be "relocatable". Unfortunately, this requirement came to me without explanation and the people who gave it to me are only messengers, so I don't know exactly what's meant.
<background> In traditional Solaris packaging, there are two mostly-unrelated concepts that could both be considered "relocation": using -R to specify an alternate root, and changing the install location by changing BASEDIR. Changing BASEDIR is used to change where the software is installed on the system, for storage management reasons, to have multiple instances of the software installed, or for other reasons. It has a direct impact on the software involved, because that software must be prepared to have its components be in different places in the file hierarchy. This is, I believe, what SVR4 packaging documentation calls "relocatable". -R, on the other hand, is used to manipulate a different "system". It says "manipulate that system with its root over there". It is used, for instance, when installing the OS, where the currently running system has its root on the install media and packages are being installed on the file system with the root on the hard disk. Traditional Solaris packages can be compliant with neither, either, or both of these kinds of relocation. </background> Which of these meanings is intended in this requirement? The hints that I have gotten suggest that the intent is that the packages must be -R compliant, that they must be installable to an alternate root. If so, this is easy: as far as I can tell, an IPS package can't *not* be alternate root capable. If, however, the requirement is for BASEDIR-style relocatability, my job gets harder. There are two important levels to BASEDIR-style relocatability: install-time and run-time. Achieving BASEDIR-style relocatability at install time is relatively straightforward: all of the paths in the package must be relative to the BASEDIR, and none may be absolute. Achieving BASEDIR-style relocatability at run time is another story entirely, requiring that the application be prepared to dynamically find its other components instead of assuming fixed paths for them. I would hope that IPS handles packages that are, in this sense, non-relocatable. Many packages will want to deliver files into fixed system locations (e.g. /etc/rc*.d, /var/svc/manifest, et cetera). However, if IPS isn't capable of handling non-relocatable packages, I can relatively mechanically rearrange my packages so that they are always relative to / and contain no absolute paths. That would address the install-time issue with relatively little work. The run-time issue, however, is non-negotiable: our application is not prepared to be installed into alternate locations on the system, it would be a substantial effort to make it able to handle alternate installation locations, and we have no identified customer requirement to handle it. So... please tell me that what was meant was -R compliance and that IPS handles packages with relocatable and non-relocatable files, and that there is no way for an IPS package to violate the -R constraint. If that's the case, the my requirement is met and I'm happy. Comments? _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
