As part of the conflicting actions wad, I introduced the notion of an overlay action. An action can be tagged with overlay=true and it should be plopped down on top of whatever's there (this is for duplicate files, not the other types of conflict). It was intended specifically for the slim_cd case (which I'm told is no longer used), not for general purpose use, which is why it's not documented.
I discovered this weekend that it doesn't quite work, and one of the webrevs I sent out fixes it and the test that was supposed to catch the problem. Now, for general purpose use, we need to require the package delivering the original action to cooperate, as you've outlined. 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. 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 think disentangling this from the preserve attribute (we can make them play together, though) would probably be best. Danek _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
