On Aug 21, 2012, at 15:26, Jeremy Lavergne wrote: > Clemens: i.e., abort the build and tell the user: you have glib2-devel, > please build with +glib2_devel
I'll just chime in about this point. I don't remember why libpixman-devel, cairo-devel, pango-devel and glib2-devel were originally created, but I keep them going because it corresponds to these projects' release strategies of releasing a number of unstable versions (with odd-numbered middle digits) before releasing a new stable branch (with even-numbered middle digit). These ports serve a purpose for me, as the maintainer of these ports, in that I get to try out a new branch before it's finalized and become familiar with any new problems this may bring. For example the new unstable 1.31 branch of pango was just started, and in trying to update pango-devel, I discovered that pango now has a dependency on a new library that I'll need to make a portfile for first. By discovering these issues early, I can have a fix ready so that by the time the new stable version is released I can publish the update that much sooner. For users I expect there would be no benefit to trying to use these unstable versions. The only reason another port should declare a dependency on a -devel port is if that other port uses features just introduced in this new unstable version. The only port currently declaring a dependency on glib2-devel is gobject-introspection, in a glib2_devel variant, because apparently a patch is needed to support the new version of glib2. Hopefully that patch will soon be integrated upstream and no longer be necessary in the port, thus eliminating the need for this unusual variant. Ports declaring dependencies on any ports where -devel versions also exist should do so using a path:-style dependency so that either the stable or the unstable version could satisfy the dependency. See #14540. Users electing to install -devel dependencies should probably disable the use of precompiled binaries because although source compatibility between versions of these libraries is typically good, library changes could sometime occur which necessitate a rebuild. There's also graphviz-devel, which uses (by default the stable versions of) all of the aforementioned libraries, but here there is some justification for users to use it, since the graphviz developers release new stable versions very infrequently, but their unstable versions remain of very high quality. _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo/macports-dev
