On Fri, 22 Jun 2007, Juan Manuel Palacios wrote:
2- to include some variants naming guidelines like
- devel is not a variant name, it is reserved for different ports that install different version of a single package (quite a few ports have a devel variant actually)
Agreed on the first count. On the second one, maintainers of those ports should be ping'd to correct that, 'devel' should be reserved for a foo-devel port.
I have followed the discussion on this point, and the consensus is very clear: a port that installs, say, the Subversion head of a package foo rather than a stable release of foo should be a separate port called foo-devel rather than a "foo +devel" variant of the port foo. In light of this, though, could somebody offer advice how to handle the following situation that comes up in my effort to try to get Macports to build GnuCash with the quartz version of gtk: Currently, for this to work, some of the low-level libraries (e.g. Cairo, gdk) must be bult from HEAD rather than a stable release version. However, there are then many levels of intermediate libraries (e.g. libglade, etc.) which are built on top of this, who don't really care about which version of Cairo or gdk was installed, they will compile with either the stable release or these head versions; and they'll run with either under X11, and run with the head versions under Quartz (although the X11 vs. Quartz choice has to be made at the time the low-level libraries are built, it can't be changed/selected at the time the intermediate libraries are built on top of them). Finally, gnucash itself doesn't care about any of this stuff, it builds and links with any sufficiently up-to-date versions of the intermediate libraries. Now, the quartz/x11 choice is (in most cases already before I got there) handled by variants on the low-level libraries, which works nicely: the higher layers have their dependencies satisfied and they build and link and if you selected +quartz below you get apps that open up right in quartz, otherwise X11 has to be running. However, I understand with the HEAD version stuff the proper procedure is to make other ports, e.g. cairo-devel. But now how do I handle the higher layers? Do I have to duplicate all the ports that depend on cairo to have a version that differs only in that it depends on cairo-devel? But duplicating information creates maintenance headaches, and libglade-devel ought to be a port of libglade which is based on libglade development code, not a port which uses stable release code of libglade but links with devel versions of underlying libraries. I could call it libglade-devellibs, but there is still the code duplication issue. Moreover the problem is worse at the gnucash level: there is already a gnucash-devel port tracking the 2.1 series and a gnucash port tracking 2.0. Either can compile with the quartz low-level libraries, so do I need a gnucash-devel-devellibs (and a gnucash-devellibs)? So you can see why prior to this thread I was planning to use +devel variants on the low-level libraries in parallel with the +quartz variants, then all these dependencies would be satisfied naturally. Given that by MacPorts current policy the head version of Cairo has to be a separate cairo-devel port, any suggestions on how to handle the layers built on top? As far as I have seen, there's no way to have an either/or dependency. Is there a way to make a dummy port whose only purpose is to ensure that either cairo or cairo-devel had been installed? If so, what should it be called? (cairo-ensure?) And what should/will happen when you "port install gnucash" and it recursively gets to installing cairo-ensure? (i.e. can it be engineered to build cairo or cairo-devel? And if so, how would that choice be controlled? Would it be legitimate for cairo-ensure to have a +devel variant which would build cairo-devel to satisfy itself, with the default to build cairo? ) Thanks for any policy guidelines and/or implementation suggestions for handling this situation. Regards, Glen