Portfile guidelines (was [26328] trunk/dports/gnustep/Etoile/Portfile)

[Glen Whitney]

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