I promised yesterday I was going to write an email explaining what this is about.
This has got everything to do with reproducible package builds, and the complexity that's package version numbers. First, here's the situation before the change --------------------------------------------- Take minitube-1.5, for instance. Among other things, it has RUN_DEPENDS = multimedia/gstreamer-0.10/plugins-base this ends up in the package as something like this: @depend multimedia/gstreamer-0.10/plugins-base:gstreamer-plugins-base-*:gstreamer-plugins-base-0.10.35p0 when you want to update a package, very often, the package name itself won't change. So when do we update ? pkg_add actually looks at the depend lines in the package and compares them. That is, the @depend multimedia/gstreamer-0.10/plugins-base:gstreamer-plugins-base-*: part is used as key, and the gstreamer-plugins-base-0.10.35p0 part is used for further comparison. If the set of keys change, the packages won't be comparable based on depend line, and normally, you're supposed to bump the REVISION. Otherwise, pkg_add will complain it doesn't know which is the newest package. Prior to the most recent change, the RUN_DEPENDS was used as-is. Let's look at net/avahi, it contains: RUN_DEPENDS-gtk = net/avahi,-ui,no_mono,no_qt3,no_qt4 thus, the plist for avahi-gtk-0.6.30p2 contains: @depend net/avahi,-ui,no_mono,no_qt3,no_qt4:avahi-ui-*:avahi-ui-0.6.30 However, this is somewhat strange, because the no_mono,no_qt3,no_qt4 part *is* a pseudo-flavor: it is just pertinent to the build, but not at all for a binary package. avahi-gtk would be happy with an avahi-ui that would come as @depend net/avahi,-ui,no_qt4:avahi-ui-*:avahi-ui-0.6.30 But this doesn't work, because the binary packages don't know about pseudo-flavors, and thus net/avahi,-ui,no_qt4 and net/avahi,-ui,no_mono,no_qt3,no_qt4 are completely different things, thus the packages will be different, and non comparable. The change itself ----------------- Some time ago, I came to the realization that some stuff were better left to the depending port. We always went there to get the build package name anyways (avahi-ui-0.6.30), but we also decided to get there to grab the pkgspec (the avahi-ui-* part). That's how ports depending on python "magically" got their python->=2.7,<2.8 spec without having to say anything. For instance, youtube-dl-2011.08.04 has: @depend lang/python/2.7:python->=2.7,<2.8:python-2.7.1p11 So I realized I could go to the depending port for the pkgpath *as well*. This has the neat effect of putting back the path in a standard order, and of removing pseudo-flavors entirely... it also creates "full" pkgpaths every time. There was some fallout: all of a sudden, *a lot* of @depend lines in packages would change, and I would need to bump all the affected packages (1980 ports to be exact). Because alongside pseudo-flavors, all multi-package dependencies would have a subpackage appended if it wasn't already there. The result ---------- Let's go back to our examples. minitube got bumped to minitube-1.5p0 it now sports @depend multimedia/gstreamer-0.10/plugins-base,-main:gstreamer-plugins-base-*:gstreamer-plugins-base-0.10.35p1 because of the subpackage part. youtube-dl-2011-08-04p0 sports: @depend lang/python/2.7,-main:python->=2.7,<2.8:python-2.7.1p12 for the same reason. More interestingly, avahi-gtk-0.6.30p3 now says: @depend net/avahi,-ui:avahi-ui-*:avahi-ui-0.6.30p0 That's right, the pseudo-flavors are completely gone. This triggered a small bug in pkg_create (net/avahi,-ui, in that context, means "the -ui subpackage of net/avahi with an empty flavor, not a default flavor") which is now fixed. Why this is cool ---------------- well, the previous way pkgpaths were stored, you had to be really careful how you presented stuff, because equivalent paths would end up as different strings, and thus divergent paths stored in a package, with ill effect. For instance some/dir,flavor1,flavor2 and some/dir,flavor2,flavor1 are now completely equivalent for package building. Also, mentioning a subpackage explicitly (or not mentioning it) won't change the string recorded in the package. And finally, the new version *doesn't care at all* about pseudo-flavors. So, if you want to depend on print/poppler,no_qt,no_qt4 or print/poppler the resulting @depend line will be the same: it will be something like: @depend print/poppler,-main:poppler-*:poppler-0.6.17p1 This can solve some nightmarish situations between subpackages in the same port with pseudo-flavors, where you had to be very careful about which pseudo-flavor you were depending on if you wanted to have reproducible results. Thus removing a lot of the interest of pseudo-flavors to avoid building things (looking at such cases, the current situation is slightly wrong in a lot of directories). There's also the very real possibility to tweak pseudo-flavors in dependencies between "individual" builds and bulk builds thru dpb. So, taking poppler as example again, we could have an individual port depend on print/poppler,no_qt,no_qt4 and when it's build as part of dpb, it could depend on print/poppler instead, thus avoiding building poppler once without qt/qt4 support and rebuilding it later with qt and qt4 support. Stuff to do ----------- * Document the user visible parts, * Experiment with a print/poppler module that would turn a poppler dependency into something like: MODULES += print/poppler MODPOPPLER_NEED += qt LIB_DEPENDS += ${MODPOPPLER_PATH},-qt * Fix a bug on BUILD_PKGPATH construction and deal with fallout (currently, the distinction between empty FLAVOR and default FLAVOR is not done correctly) * Audit the tree for proper usage of BUILD_PKGPATH/BASE_PKGPATH (shouldn't be too hard, there are less than 150 ports in that list)