On 03/22/10 12:18, Mark J. Nelson wrote:
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.)
So the question is whether blending vs merging is done at the package
level vs the action level; do we want packages w/ some actions merged
(w/ variant tags) and others (where they don't collide) left alone
(blended)?
- Bart
--
Bart Smaalders Solaris Kernel Performance
[email protected] http://blogs.sun.com/barts
"You will contribute more with mercurial than with thunderbird."
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
