On 21/03/11 01:28 PM, Danek Duvall wrote:
Shawn Walker wrote:1) File Actions =============== Add additional values for the preserve attribute on file actions: custom-true custom-renameold custom-renamenew The 'custom' prefix on the above values simply indicates that the editable file allows another package to deliver a custom version. Otherwise, the behaviour is identical to what rename uses today.Why custom-renameold and custom-renamenew? Seems to me that if you're going to lay down a customized file, you probably don't care what was there before.
+1
I expect this will most likely be done at initial install, at which point there will have been no local customizations. If the file is simply delivered mode 444, then users can have some warning that it's not to be edited.
I wouldn't necessarily rely on permissions to convey the idea that a file is not meant to be changed - consider the following two files: /etc/nsswitch.conf. /etc/mail/sendmail.cf If you're going to run a mail server then the latter is most definitely going to need to change. Whilst some people may continue to do this interactively (after building a new .cf file), some may choose to install the new .cf file via IPS. And as much as we hate to admit it, I think that all of the driver .conf files fall into this category too because they often represent the only way to tune the driver correctly for the customer. Darren _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
