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)
