Luke Shumaker wrote : > the conflict should be > happening with your-freedom->firefox, not iceweasel->firefox.
that seems completely reasonable - i quite imagined that this was how it worked already and am surprised to learn that it was not implemented that way from the beginning - it seems obvious from a design standpoint that the blacklist package should conflict with everything under it's concern and not to merely 'provides" anything - while the replacement dependencies themselves may or may not conflict with anything for clarity, this is the intended semantics of these package relationships according to archwiki: * any number of packages that 'provides' some feature can co-exist on the same system * packages in which either of them 'conflicts' are mutually exclusive * 'replaces' is for obsolete packages that this package replaces - the main reason to use 'replaces' is when the package should be automatically removed during a normal -S sync and replaced automatically with the NEW package that is said to replace it - 'provides' and 'conflicts' are only meaningful when specifically installing the new package - so it seems that 'replaces' does not fit the blacklist use case in any way note that this seems to be assuming that a package will only ever 'provides', 'conflicts', or 'replaces' one single other package - what if for example, packages 'foo' and 'bar' both provide 'foo' and then a parabola replacement would need to conflict with both of them - would the current system allow for that?
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Dev mailing list [email protected] https://lists.parabola.nu/mailman/listinfo/dev
