overlay package.mask stacking; injected, or standalone?

[avuton]

When I was trying:

rocket / # pmerge media-sound/flac

I got:
Error in configuration:
Instantiating default domain 'livefs domain':
Caught exception "atom '-media-libs/tunepimp' is malformed: error -media-libs/tunepimp" instantiating pkgcore.ebuild.domain.domain

I had to find out where the file was, so I strace'd it back to the musicbrainz overlay, which had shown the following:

# This overlay requires tunepimp to be useful at all - reverse the mask.
-media-libs/tunepimp

Commenting out this line made the pmerge succeed.

I'm not sure weather this is correct syntax or not, someone else may know better than me.

Thanks for the great program and your time.

[ferringb]

mmm. fun one potentially.

What's occuring is that at the root level, -atom in package.mask is daft; logic is straightforward, root level you can't negate anything since it's the start of the incremental chain.

overlays are a wee bit different though. The code currently doesn't generate seperated visibility stacks (fancy term for package.mask sets per repo target), but *does* collapse in all repo p.masks- honestly not sure about injection (effectively) of an overlays package.mask into the profile stack.

basically, for overlay repos can inject in the overlays package.mask, pretending it's part of the root node, but that can probably cause incremental issues with the users profile.

Thoughts/comments?

[masterdriverz]

overlay the overlay's p.mask over the parent repo(s) p.mask(s) by default, but allow this to be overridden in the config definition would be my personal preference.

[jokey]

as we can just define different domains now and specify masking by hand if needed, I'd say we're safe here. --domain ftw