Hello?

Jordan Brown wrote:
> 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
> 

_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss

Reply via email to