On 03/18/10 05:42 PM, Bart Smaalders wrote: > On 03/18/10 16:26, Mark J. Nelson wrote: >> Howdy-- >> >> A question in #onnv jogged my memory this afternoon, and got me thinking >> about merge.py. >> >> I cc'd Bart and James because I know they've both done some >> brainstorming in this area. >> >> Is anybody actively working on this? I was kind of wondering if >> time-of-merge was the best time to solve packaging problems like >> SUNWrmod and SUNWonbld. If we could tag an action with a special >> variant value that would tell merge.py "always include this object," >> instead of having it be strict about mapping source repositories to a >> single variant value, then it seems like we could do at least the >> special cases we've already considered.
I'm also interested in the answer to the question "Is anybody actively working on this," because I'm pursuing this as a fix for SUNWonbld and SUNWrmod delivery. I don't want to step on any toes, if folks are already working in the merge.py space. But I also don't want the scope of what I'm doing to explode into a full productization of merge.py. (Nothing against that, but the delivery issues are higher priority for me.) > This could work but it certainly raises some interesting error > conditions; if variant A has an action marked > "always-include-on-merge=true" but variant B is not marked that way, > things are > tricky. In addition, I anticipate multiple merges (debug/non-debug, > sparc/x86) so perhaps > > "include-on-merge=variant.arch" would be a better approach. > > Actions to be included on both debug/non-debug and arch* merges > would need both tags... Yes, I agree that any such tagging needs to be explicit about the specific variant(s). And a multi-variant merge should be associative, which implies that tags that are not applicable to the current variant should be preserved. For the case of needing both tags, I don't think we currently have any such examples. We don't have any cases where we explicitly want to build an object as only DEBUG (or non-DEBUG) and deliver it for both variants. Tagged actions should probably be delivered by only one input repository. I haven't thought that through completely, but it seems like the default merge.py behavior would be an error for such an action. (Default behavior being to coalesce actions where the key attribute and content hash are identical, but to deliver variant-specific actions when the key attribute is identical but the content hash differs, I believe.) Continuing to ramble, --Mark _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
