On 03/23/11 10:10 AM, Bart Smaalders wrote: > On 03/23/11 07:51, Mark J. Nelson wrote: >> On 03/22/11 12:46 PM, Bart Smaalders wrote: >>> On 03/11/11 11:27, Bart Smaalders wrote: >>>> http://cr.opensolaris.org/~barts/17908/ >>> >>>> https://defect.opensolaris.org/bz/show_bug.cgi?id=17908 >>> >>> Well, I got back to this after a couple of distractions and >>> other bugs; this wad now fixes a couple more bugs. >>> >>> 17908 pkgmerge should have a blend mode >>> 18051 pkgmerge may attempt to get files from wrong repo >>> 18060 pkgmerge doesn't use latest fmri of packages being merged like it >>> thinks it does >>> >>> Note that non-identical duplicate actions in any single input >>> manifest will cause the merge to fail; the creation of such >>> w/ inappropriate use of the pkg.merge.blend attribute is >>> included in this... >>> >>> - Bart >> >> My question about doing three two-way merges vs one four-way merge still >> stands. Is it worth documenting, or giving the pkg.merge.blend >> attribute a value to match the variant name? >> > > Sorry - missed that comment in review. > >> That was a long winded way of saying "I think that pkgmerge.1.txt should >> include a warning that 'Merging previously blended packages may have >> unexpected results. If you want to blend repositories along multiple >> variants, you should do so using a single invocation of pkgmerge.'" > > It seems to have perfectly expected results.... is this because you > want to blend debug first and then arch later?
Yes. More generally, I want to not care about ordering. Stripping pkg.merge.blend means that only the first merge will be blended, and subsequent merges will not be. So ordering is important. My argument is that this is nonintuitive behavior: A + B != B + A. >> Another implication here is that the current behavior is almost >> certainly desired, and should not be an error: silently publish >> variant-specific actions when blended actions have conflicting payloads. > This is quite counterintuitive, and Brock asked for a test case. I > decided that if your source manifests contain duplicates after (or > before!) blending, you have a problem, and the merge fails with a > listing of the conflicting actions. If I understand what you're saying, then we could never merge on both arch and debug. Which probably means that I'm confused. For the onbld example, we have (among others) > file path=opt/onbld/bin/$(ARCH)/findunref This will result in two different values for the path attribute, and each of those two values will have two unique payloads, one for debug and the other for nondebug: > file path=opt/onbld/bin/i386/findunref variant.debug=debug > file path=opt/onbld/bin/i386/findunref variant.debug=nondebug > file path=opt/onbld/bin/sparc/findunref variant.debug=debug > file path=opt/onbld/bin/sparc/findunref variant.debug=nondebug It seems to me like we really SHOULD have four file actions in the merged, blended output. The actions should be blended on arch (because there are no conflicts there), and not along debug/nondebug (because there are conflicts there). I'm not picky about whether that happens because pkg.merge.blend specifies a particular (set of) variant name(s), or because the logic allows the conflicts to pass through as still-marked-with-a-variant actions. So aren't we now saying, for this example, that: - merge arch first, then debug: desired results - merge debug first, then arch: fails, reporting conflicts - merge on both simultaneously: fails, reporting conflicts ? That seems wrong. > Note that if the actions are completely identical, they are simply > de-duped. Right, and agreed/expected. --Mark _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
