On MacPorts some packages have variants - e.g. gtk3 is available with a quartz and a X backend. Some packages using gtk3 somehow depend on this (although the interface of the resulting library is the same, but dependencies are very different). Under the line for MacPorts the result in rare cases involving variants does depend on the order in which things are installed.
One can argue if this is a good design, but the effect that depext sorts packages prior to sensing them to MacPorts doesn't help the case. I could get around this by using finer grain conf packages, but especially during development this is not nice.
On MacPorts some packages have variants - e.g. gtk3 is available with a quartz and a X backend. Some packages using gtk3 somehow depend on this (although the interface of the resulting library is the same, but dependencies are very different). Under the line for MacPorts the result in rare cases involving variants does depend on the order in which things are installed.
One can argue if this is a good design, but the effect that depext sorts packages prior to sensing them to MacPorts doesn't help the case. I could get around this by using finer grain conf packages, but especially during development this is not nice.
See e.g. (https://github.com/ocaml/opam-repository/pull/16912). If one would add the depext lines of the 4 conf packages directly to a opam package, building would fail.