Edward Pilatowicz wrote:
wrt smf_disable.lst, it seems like this file should be empty to me. looking at the current services in this file, it seems like they are services which should never exist within a zone, not just be disabled within a zone. so if these services shouldn't exist within a zone, then the smf manifest that defines them shouldn't be installed in a zone, and if the manifests for these services are being installed within zones then that seems like a packaging bug. does what i'm saying make sense?
Ed, You are correct that these services shouldn't exist in a zone but since we're doing a p2v, the services could exist in the original physical system archive. Most SMF services are disabled based on their pkg metadata. That is, SMF services whose opensolaris.zone property is 'global'. However there are some services which should be tagged this way but aren't. Since we know those services won't work in a zone, we disable them using the smf_disable.lst to avoid users having problems with those services. You are correct that this is a packaging bug for these svcs but thats the way they currently exist. We should fix the pkg metadata but that doesn't fix the problem for people who are taking pre-existing systems which have incorrect pkg metadata and putting them into a zone. That's really the whole purpose of this conf file, to handle this well known brokeness. If all pkg metadata had always been correct and will always be correct, we wouldn't need this file. This file gives us a mechanism to handle the cases we know about which are broken. As an alternative we could remove this mechanism and simply acknowledge that there are broken pkgs which the user will have to manually fix up after they p2v. This is a mechanism which I carried over from the SVr4 p2v code so its possible we don't want it with the IPS p2v. Thanks, Jerry _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
