Bart Smaalders wrote: > Ed McKnight wrote: >> I've been reminded that one valid user action is to delete this file, >> hence it may be better for the file to be created in 'postinstall' >> rather than delivered such that deletion might create a corrupt >> package kind of state. The presence or absence of the file is >> essentially an environmental control where a subsystem takes a cue >> from presence or absence. >> >> Upgrade: interesting point. If the user has deleted the file it >> shouldn't be recreated by next pkg operation. >> >> Note that the subsystems that read this flag file are not mine to >> revise. An alternate design would read a value from the file, but >> that's not what we have. > > If your users are free to delete files at will, then things aren't
Well, subject to documentation. It's not like they're deleting the implementation of a product or picking files at random to blow away. If the user deletes the specified, documented file the product behaves one way; if the file is present (the default) the product behaves a different way. The file, if present, is empty. Contents and permissions are irrelevant. It's roughly equivalent to setting a global, persistent environment variable and modifying behavior based on its value. Do you have any comments/suggestions about the preferred way to do this under IPS? Deliver an empty file or create it after the product bits are laid down or...? thx, --emk > likely to work no matter what the design. > > If your software needs to determine whether or not various components > are installed, the "deliver an empty file" trick works fine... > > What does it mean if the user deletes the file but not the software? > > - Bart > > > Bart Smaalders Solaris Kernel Performance > [EMAIL PROTECTED] http://blogs.sun.com/barts > "You will contribute more with mercurial than with thunderbird." _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
