[Dev] [RFC] blacklist/your-freedom conflicts/replaces stragegy

[bill-auger]

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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20170917/235402b7/attachment.sig>