Part 1 of #94. This PR allows moss and boulder to emit packages with conflicts and store conflicts in the meta database.
Conflicts is being interpreted as "providers that cannot coexist with a package". In other words, if provider foo is a conflict of package bar, then any package that provides foo cannot be co-installed with bar. Therefore, a conflict is the exact same as a provider except that it is used/interpreted in a different way.
moss support is complete but needs testing. Testing is contingent on boulder being able to emit packages with conflicts, so I'm implementing that right now. I cannot get the D-boulder to build a package properly, it just says: Support for boulder is implemented and a simple test for storing/retrieving conflicts from the meta database is added.
Looking at how run_deps is collected in boulder/src/package.rs, I may be missing a few details on handling conflicts for subpackages, but otherwise this PR should be good for review.
Part 1 of #94. This PR allows
moss
andboulder
to emit packages withconflicts
and storeconflicts
in the meta database.Conflicts is being interpreted as "providers that cannot coexist with a package". In other words, if provider
foo
is a conflict of packagebar
, then any package that providesfoo
cannot be co-installed withbar
. Therefore, a conflict is the exact same as a provider except that it is used/interpreted in a different way.Support formoss
support is complete but needs testing. Testing is contingent onboulder
being able to emit packages withconflicts
, so I'm implementing that right now. I cannot get the D-boulder to build a package properly, it just says:boulder
is implemented and a simple test for storing/retrieving conflicts from the meta database is added.