On 3 July 2017 at 19:03, Rainer Müller wrote: > On 2017-06-27 11:31, Ryan Schmidt wrote: >>> ----> Installing dependency (55 of 120) 'cairo' with variants >>> '+quartz+universal+x11' >>> ... >>> Error: glib2: Variant quartz conflicts with x11 >> >> The cairo port has for years had both x11 and quartz variants that are both >> enabled by default. The glib2 port recently got x11 and quartz variants >> added, and they conflict with one another, as they do in most ports that >> have them; the user must choose one or the other. The default is x11, as it >> is for other ports that have this choice. >> >> I think the problem is that mpbb is explicitly specifying the variants when >> installing the dependencies, particularly since wine is 32-bit so it needs >> the dependencies installed with the universal variant, and when installing >> cairo with x11, quartz and universal, it is passing those variants down to >> cairo's dependencies, including glib2. > > Hm, interestingly the same would happen when trying to install cairo > while explicitly requesting +x11 +quartz variants on a clean prefix. > This can only be resolved by installing glib2 first. > >> I don't know why mpbb is specifying all the variants when building >> dependencies. It seems like it would be enough to just specify universal, >> and let the port's default variants take care of the rest. > > I think the idea was to expand default variants to the build request, > such that lookups in the failcache would match. Selecting a default > variant was supposed to have the same effect as building without > selecting variants. > > Apparently this is not true, so we should revert this behavior and only > pass explicitly requested variants. > > As I understand it, in the worst case, we would try to build a port > multiple times as the failcache entry would not match. I don't think > this will happen that often.
I think I figured out what the real problem is. I first wanted to suggest a potential solution: getting the list of dependencies in the right order, installing glib2 before building cairo. Then I realized that we already do that. The problem lies in something that I objected from the beginning: Installing 120 dependencies of wine-devel: ... - glib2 +universal+x11 ... - cairo +quartz+universal+x11 ... ----> Installing dependency (28 of 120) 'glib2' with variants '+universal+x11' ... ---> Deactivating glib2 @2.52.3_0+universal+x11 ---> Cleaning glib2 ... ----> Installing dependency (55 of 120) 'cairo' with variants '+quartz+universal+x11' ... ---> Computing dependencies for cairo ... Error: glib2: Variant quartz conflicts with x11 The problem is that we loop through all dependencies and install and *uninstall* each individual one of them. This is both inefficient and leads to problems like this one. The problem should be solved if we skip deactivation of dependencies. The only advantage of current approach is that we don't activate any dependencies if one dependency is known to fail. We could still check for that, but we should not deactivate dependencies. This should be easy and high priority to fix. Mojca
