Right now we don’t support wanting to overwrite anyway, so unless you want to consider a hypothetical future feature I am not sure why it matters. (FTR: if one were to need an opt-out I’d say ‘inclusion always trumps exclusion’ so
stage: [-/foo.so, /foo.so] would overwrite
/foo.so in the stage on account of being explicitly staged; at that point it would not matter if we have injected implicit exclusions as the user explicitly saying “stage this!” would always result in the expected behavior of overwriting whatever else was staged already).
The invisibility definitely is a concern though.
Perhaps a simple line explaining the SDK override in snapcraft’s stdout might be enough to address this?
I mean, you can’t overwrite with a different file anyway. In the end what we are really missing is a message telling the user that they can’t. Right now this is the fatal error of “$file has been staged already and your new $file is different and we don’t allow that”. Something that might be easily communicated in a non-fatal manner by some output when an SDK part was detected and the automatic exclusion injection happens “Detected SDK part, all its files are being automatically excluded from staging in parts that depend on it yayadyada https://urlwithmoreinfo”. This way snapcraft does the right thing most of the time, and at the off chance the user is getting perplexed by it we inform them why overwriting is neither support nor makes much sense.
I expect this largely is a question of which is more important from a user experience POV for snapcraft: doing the right thing 99% of the time automatically, or not doing the wrong thing 100% of the time. Or in other words perhaps: does the author of the snap need to be aware of having to do the right thing 100% of the time, or do they need to be “made” aware in case they have a 1% corner case.