While I was in the train today, I looked at some of the more arcane inner workings of MirPorts: internal dependency handling.
Packages have dependencies. There are three types of them in MirPorts: build, run and library dependencies. I won't talk about the former here. MirPorts inherited a very convoluted way of handling those dependencies from OpenBSD, including several passes over the packing list using various scripts and the infamous pkg utility. pkg is essentially undocumented and constitutes a failed attempt of Marc Espie to rewrite the pkgtools in perl. It has only one subcommand, pkg dependencies with three sub-subcommands show, solve and check.
Dependencies are declared via the LIB_DEPENDS and RUN_DEPENDS variables in the port Makefile, for example:
From there, they are passed to a recursive solver in bsd.port.mk, which outputs commands like
into w-*/pkg/depends. The four arguments are called name, libspec, pattern, and def. The @newdepend directive is for run depends and does not have a libspec. The depends file is fed to pkg dependencies solve, which replaces these lines by
@comment libdepend apr.0.9:subversion-1.4.0-0-bsddb:apr-*:apr-0.9.12-0
Note the changed order of the arguments! What it also does is resolve the dependency and write a static @pkgdep line like
on top. All of those are output into w-*/pkg/PLIST. Upon installation, pkg_add only cares about the @pkgdep directives.
There are a number of problems with this approach. I would like to replace pkg entirely by C code inside the pkgtools. The advantage is a much reduced complexity, the removal of the liability that is pkg, and more flexibility: If packages are upgradeable, the final resolution of the dependencies should be done by pkg_add when installing the package. If you have a newer version of a dependency installed, we can check if the library version matches and still allow the installation. pkg_upgrade would also profit massively, as the current implementation leaves the @pkgdep lines intact so that they are effectively unfulfilled. This project is promising but it will take me some time. Be patient.
If you want to discuss this, please use the miros-discuss mailing list.