Hi Clemens, I saw the apt-get and other implementations using CUDF. From what I understood was that the cudf solver is installed on the machine and if it is found we will send our portfile to cudf solver after interpreting and modifying the PortFile format to cudf format.
libCUDF C bindings are available so we could use that. Or we stick to the Boolean SAT solving technique? If we use Bool SAT solver, we will need to implement the wheel (didn't quite understand what it actually means, but does it mean creating the dependency tree and then finding the best plan). CUDF already provides this and in an efficient way then we could probably go with that since many package managers are implementing them. One reason would be better and clean results using CUDF. So why not MacPorts also join in the league with them :) >From our Previous discussion, >From what I've > seen, dependency resolution methods based on SAT solving expect the > complete universe of available packages and their dependency relations > plus a list of packages that should be installed after the current > action finished. Generating the complete list with accurate dependency > info by executing the Portfiles would take ~15 minutes and is thus > out of the question. > > We do have a cache of the information, which we call the port index. > However, since Portfiles can execute arbitrary code, some Portfiles > may currently depend on the behavior that they are being evaluated > during dependency calculation (e.g. by changing their depends_lib > depending on the variant selection the user has given). We should > figure out a solution for that, for example by > (a) somehow adding the effect of a variant on dependency relations > to the portindex, so we could tell what the dependencies of > foobar +bar +baz were without actually running the Portfile. As there is already a cache with the dependency information, we can update/better create another cache (cudfindex) with the required information from PortIndex and checking for variants when we run port install. This might not take ~15 minutes or so I guess as most of the information is already there. Also, it depends on number of variant combination as Mihai had mentioned. > The problem is that this is not static. See above. There are 2^n* > different states for n variants. For a port like mplayer-devel (or my > own ports, mpv and audacious-plugins), the amount of variant > combinations is *very* high and for each combination the dependencies > differ. > > You do NOT want to record this in PortIndex, which is supposed to be > fast cache. I don't think normal users will always make use of variant, also if they do they won't keep changing the variants too much. Considering the same variant would be passed in future, we could probably make use of this cudfindex. Also, I would prefer stable and reliable build rather than a fast and shaky installation. -- Jackson Isaac S6 B.Tech CSE Amrita Vishwa Vidyapeetham jacksonisaac.wordpress.com Github/JacksonIsaac _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
