Setting up MacPorts libsolv branch and Testing libsolv search

Clemens Lang cal at macports.org
Tue Jun 23 01:24:03 PDT 2015


Hi,

----- On 23 Jun, 2015, at 01:07, Joshua Root jmr at macports.org wrote:

> How are you planning on handling variants? It seems to me that the only
> tractable approach would be to evaluate the package universe lazily,
> running mportopen to get data from portfiles only when it is required.

I've been in contact with the developer of libsolv about that and my
current approach would be to represent every variant separately in the
package universe, e.g. a port A with the variants var1, var2, var3 with a
conflict between var2 and var3 and an additional dependency on C in var1
would become

 portA+0 (i.e. without variants)
  Provides: portA

 portA+var1
  Provides: portA
  Requires: portC

 portA+var2
  Provides: portA
  Conflicts portA+var3

 portA+var3
  Provides: portA
  Conflicts: portA+var2

Then, after solving the dependency problem, post-processing would fold the
results back into a single port name with multiple variant selections.

This would require accurate dependency information for variants. I think that
can be achieved by instrumenting the various depends_*-* operations and
storing their effect during PortIndex generation. Of course that also means
that stuff like

variant foo {
  if {[run arbitrary code here]} {
    depends_lib-append port:foo
  }
}

will no longer work, but I'd argue that this should not be legal anyway. We
only need to be able to switch the default variant programmatically, and we'll
find a way to do that.

-- 
Clemens Lang


More information about the macports-dev mailing list