Chris, I'm already down to a pretty minimal list of Solaris packages, thus the need to start investigating the need to look inside the packages to see what's unnecessary. In terms of support, yeah that's a real sticky issue. I'd like to take the position that if a problem is encountered in such a scenario, then support should hinge on whether it can be reproduced on a standard OS configuration.
-- Jim C Chris Quenelle wrote: > I assume you want to remove anything unneeded. So start with > the largest files (library, binary, whatever) and work your way > downwards to smaller files. > > You could look at the package dependency map, as a way to understand > which binaries go with which libraries. > > You might try sorting all packages by size, then looking at > the largest package first, and see if you can leave out that entire > package (and the things that depend on it). > > You could try using "pkgrm" on an official Solaris install since > that would warn you about dependencies. Again, start with the > largest package the might be unused. > > It also might help to identify major sections of OS functionality > that you won't be using NFS server, print server, etc, etc. > You could try looking at svcs command for a list of the various > runtime services that are available, then hunt down the files > on disk that support the ones you don't need. > > Please understand that your partial Solaris image will be untested. > Any guarantee against crashing and/or subtle bugs, would have to > come from your own testing. > > > --chris > > > Jim Connors wrote: > >> >> Working to create a minimal embedded Solaris configuration. With a >> modest investment, it's not too hard to boot a version with a >> footprint of 50-60MB. One of the first tasks here is to select only >> the critical Solaris packages to install. There are many that have >> serious issues with Sys V packaging; I'm not one of them however, >> current Solaris packages are too large (not granular enough) to >> address the embedded market. >> >> The end result is that in a 50-60MB config, there's still lots that >> can be trimmed. One of the potential candidates is the plethora of >> shared objects. I was trying to figure out an automated way to >> determine which shared objects are not being used. One such idea >> was to create script to run ldd(1) on all executables and gather up >> the referenced so's, and remove those that weren't referenced. This >> didn't work. >> >> Would there by some automated way to determine which shared objects >> in a system may not be referenced? >> >> Some libraries, notably those that have separate subdirectories under >> /usr/lib, do not have a version (e.g. .so.1) associated with the .so >> files. Are these different? >> >> Thanks, >> -- Jim C >> >> >> _______________________________________________ >> tools-linking mailing list >> tools-linking at opensolaris.org >
