On 03/02/12 08:58, Alan Coopersmith wrote:
On 03/ 1/12 10:33 PM, Shawn Walker wrote:
On Mar 1, 2012, at 8:09 PM, Alan
Coopersmith<[email protected]> wrote:
While working on the fix for 7103352 (TrustedExtensionsPolicy should
be marked
preserve=renamenew) the results I saw during testing confused me.
I added both overlay=allow& preserve=renamenew to the manifest for the
TrustedExtensionsPolicy file. If the file was edited, then installing
an update that had a new version created TrustedExtensionsPolicy.new.
(There was no warning this had happened - if I hadn't been testing for
it, I'm not sure I would have or could have known without doing a
"find . -name *.new" - how are admins/end users supposed to know
about this?)
Correct, there is no warning as its not an exceptional event.
No one has requested that we notify the user of these changes,
although there's no technical reason preventing a notification at the
end of an operation as we do for services being restarted, etc.
Keep in mind that we assume most installations are scripted, so it's
likely messages will be ignored.
The old Solaris upgrade mechanism produced a log file at the end of upgrade
with a list of files for which the rename* class action scripts had made
changes
so that admins could go back to review and see if they needed to merge
changes.
(I occasionally did, but often, like many admins, just ignored the list.)
A warning isn't the best mechanism, but something better than find *.new
is needed - perhaps simply a flag to pkg verify that shows files with
preserve
actions that don't match their packaged checksums, due to either editing or
overlays.
We've talked about the verify option before. And at the least, we could
add the .new and .old files to the pkg history entry.
Please note that the action with overlay=true will only have preserve
semantics if preserve has been set on it. The preserve on the original
action being overlaid is not accounted for (intentionally). An
overlaying action is more like an override; not a simulation of user
modification.
Ah, and on going back to read the man page, I see it says that and I had
misunderstood before, thinking it was the preserve attribute on the
overlay=allow file that mattered.
Right, the reason it was done this way is so that if you deliver a file
with overlay=true, but without the preserve attribute, then
modifications of that file will cause pkg verify to fail and pkg fix to
repair it.
Think of it as a way for an administrator to say "this *is* my custom
configuration and it should not be modified".
Whereas if they place a preserve attribute on the action with
overlay=true, the overlaying file is treated as a custom sample
configuration and modifications are subject to whatever preserve rule
has been set.
-Shawn
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
