>> 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)?
I can't come up with any real examples to support a need for action-level blending. I also can't come up with any concrete reasons to restrict it to package-level. Since merge.py is not yet product-quality, it seems kind of backwards to decide based on the ease of updating that script. There's a slight ease-of-maintenance difference, in that specifying a single package property is easier than specifying multiple action properties. That could be mitigated by using a transform to set a property based on pattern matching of /$ARCH/ in the path attribute. I don't feel strongly, but don't see a strong motivation to not take the less restrictive approach. (Meaning I lean towards action-level blending, but don't feel passionate about it.) --Mark _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
