On 03/21/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
The 'custom-' prefix indicates that it's acceptable for another package to deliver a new file to treat as an 'override' for this action.
going to lay down a customized file, you probably don't care what was there before. 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.
But you do care about what was there before. For example, what happens if you never deliver a package that customises an editable file or remove the package that delivers the customisation?
I think disentangling this from the preserve attribute (we can make them play together, though) would probably be best.
Bart and I thought it best that only editable files could participate in this scheme, hence tying it to preserve since that's what is used to indicate that a file is editable. But perhaps I'm misunderstanding.
-Shawn _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
