Do we really want to generate an error for unfound conflict ?

[cournape]

ATM, if a package A declares a conflict on B, the rules generation will fail if no candidate is found for B. I am not sure that's the right behaviour (if package B is not in the repositories anymore, you should still be able to install A after all).

[johntyree]

I guess it depends on whether you view the ecosystem as closed or not. If we assume that we have all the packages we know about, then have an easier time catching potential errors. I prefer this approach.

If we don't assume that, then there's nothing to prevent writing pil 1.0.0-1; conflicts (pilow) instead of pil 1.0.0-1; conflicts (pillow). I don't see why we would want to allow this if we don't have to.

Removing a package from the repository entirely is already going to require updating the metadata of all the reverse dependencies. Requiring that it be done for the conflicts doesn't seem unreasonable to me.

In the end I would rather not permit packages to be removed, just made unavailable.

[cournape]

That a good point. But note that even if we were to update all the reverse dependencies (w/ new builds), every existing package marking a conflict with that removed package won't be installable anymore.

[johntyree]

every existing package marking a conflict with that removed package won't be installable anymore.

Sure, but so will every previous package that used to depend on it. That's why I'm saying we shouldn't remove packages, just flag them as ineligible for installation if they are deprecated or something.

[johntyree]

Alternatively, we could have a whitelist of packages that have been removed and are ignored if they appear in metadata. That would be fairly safe, I think.