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.
However, if the edit was done by delivering a new package with overlay=true,
then installing an updated version of the Solaris package that had a new version
did nothing - no .new file was created, it was just silently ignored. From my
reading of the overlay=allow description, it's supposed to still follow the
preserve handling for updates, so why didn't it make a *.new file in this case?
Did I misunderstand or is there a bug?
There a few things unclear here. First, was the file being overlaid edited
before installing the overlaying action?
Two, what preserve attribute was set on the action with overlay=true?
None.
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.
--
-Alan Coopersmith- [email protected]
Oracle Solaris Engineering - http://blogs.oracle.com/alanc
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
