May 8, 2003
New Approach to Building Solaris Packages
Have been carefully thinking about the process for building Solaris packages over the past day or so, have taken a new slant to my problem. Didn't spend a ton of time trying to track down how other people have dealt with this, want to get moving.
I should note, the problem isn't always applicable. Sometimes the application is intended to be installed in a single, new directory, which keeps a 'make install' tidy and easy to package up. Also, in some instances you can tell 'make install' to put the files in a different location from the config, which also keeps the dirs and files in an autonomous location for easy packaging.
If the above is not true, and config/'make install' desperately need to use a common directory where it will mix in files, I have succesfully used the below method, which essentially limits the build of the prototype file by a -mmin option where anything modified in the last 10 minutes becomes part of the package prototype.
Note: This will not work seamlessly if you are installing into a place where other users are actively making changes. Ensure the system, or at least the install dir is quiet through the process. If system isn't quiet you will get additional files in the package protype and will have to manually go through and remove unwanted files.
1. find . -print > ~/before_install.log - create a log of dir tree before install
2. Install the application/library with 'make install'
3. find . -print > ~/after_install.log - create a log of dir tree after the install
4. find . -cmin -10 -print | pkgproto > prototype - put all files modified in last 10 minutes in the package prototye - make sure this is run within 10 minutes of install
5. create pkginfo file, make package
6. install package - shouldn't install any files, because they are already there
7. remove package - should remove all package files
8. find . -print > ~/after_pkg_remove.log
9. compare the after to the before - there should be no differences. if there are, determine what needs changed in the prototype file and rebuild package
10. install package
11. to be completely sure you got everything, run a diff between a dir tree and the after_install.log file, should be identical, with all files and dirs from the new app/lib
I'm not saying this is the best solution, but it allowed me to get perl 5.8.0 installed correctly with a package that can be used on all our machines.
Posted by mike at May 8, 2003 10:37 AM