Package Conflicts

Conflict Detection & Resolution

A conflict is an issue that arises when a user attempts to install a set of incompatible packages alongside one another.

MPM handles both the detection of conflicts and (if a fix exists) the resolution of said conflicts.

Automatic Conflict Resolution

MPM is capable of detecting and resolving certain types of conflicts between packages. These are special cases which can allow for purposeful overriding of existing files within packages and other useful behaviour.

File overlaps

One such conflict occurs when two packages attempt to install the same file.

Example

Let A and B be two different packages, where both share one or more file declarations with the same path (e.g. "config/betterstorage.cfg").

If B depends upon A, the files installed by B will take precedence over the files installed by A. Otherwise, A and B are said to be in conflict, and installation will abort.

To resolve such a scenario, a manual conflict must be specified.

Manual Conflicts

Certain conflicts are outside of the scope of MPM and cannot be automatically detected. For conflicts such as these, packages may manually specify the presence of a conflict with other packages.

Conditions

The condition attribute must contain a pattern which holds true only under circumstances where the conflict is present. All conditions in a specified set must be true, but a condition may contain an or attribute of an array of further conditions; this attribute must contain further conditions, if it exists, or it will always return vacuously false. A similar and attribute is supported, and will return vacuously true for empty sequences.

Resolutions

Resolutions are a set of rules on dependencies that change the behaviour of the resolver. They may force and/or decline specific dependencies.

This acts as a filter upon dependency resolution, requiring builds that are dependent upon specified packages/interfaces or refusing any that are dependent on the specified packages/interfaces. If a conflict does not specify a resolution, any configuration that introduces the unresolvable conflict will fail to apply. If a package is targeted by a conflict, the inverse condition ([a, b]=>c >> [c, b]=>a) on the targeted package resolving as true will allow a package to submit resolution to the original package's unresolvable conflict, allowing the maintainer of either package to submit fixes to their interactions.

The following example conflict

//A condition requiring both Bukkit and Forge interfaces
condition: {
    //'and' & 'or' may be used (and can be nested)
    // 'and' requires all conditions to be satisfied
    // 'or' requires any condition to be satisfied
    and: [{
        //any version providing "bukkit" fits
        interface: {name: "bukkit", version: "*"}
    }, {
        //excluded version attribute implies '*'
        interface: {name: "forge"}
    }]
},
//specify a means of resolving the conflict
resolution: {
    //modifies resolver behaviour
    dependencies: {
        //requires items for resolution
        force: [{
            interfaces: ["forge"]
        }],
        //disqualifies resolutions containing items
        decline: [{
            packages: ["bukkit"]
        }]
    },
    //modifies installer behaviour
    install: {
        //adds packages to the configuration
        packages: ["dynmap-cb-bridge"]
    }
}