Portfile guidelines (was 
Juan Manuel Palacios
jmpp at macports.org
Fri Jun 22 15:09:30 PDT 2007
On Jun 20, 2007, at 11:29 AM, Yves de Champlain wrote:
>> I see... it did not seem to me like you were building a different
>> version of the package, indeed, but your commit log did raise my
>> eyebrows ;-) So if you're still working with the same source tree,
>> maybe we could think up some different names for your variants?
>> (Yes, in this case two different ports would not be the best
>> approach, most definitely). I was thinking, if possible with your
>> source tree, maybe you could split the full build and the debug
>> functionality in two different logical blocks? Thus your port
>> would have something like +full (or whatever other name is more
>> appropriate for the full build) and +debug (which would enable
>> building with debug symbols). Based on that, full + debug == your
>> current 'devel' variant. That's just a suggestion that I'm hoping
>> is not too outlandish with respect to Etoile, of which I know
>> nothing about.
>> I know we don't have a written on stone mandate for variant
>> naming, and maybe we should actually have it, but for the time
>> being I believe working with the jurisprudence set by previously
>> accepted practices is a fairly reasonable thing to do. In this
>> case, said jurisprudence suggests a +devel variant is something to
>> avoid in favor of *-devel ports. I know this is not your
>> particular case with Etoile (you're not changing version number),
>> as you made clear, but then I'd say "lets avoid the confusion
>> too" ;-)
> This seems like a very good solution to me. I am definitly in
> favor of coherent naming schemes and guidelines.
Totally for a variant naming guideline doc! But on that topic, read
my recent message (cc'ing this list) to Maun Suang on the MacPorts
guide, this type of document should most definitely be part of the
"official" guide. Would you care to write a first draft and
coordinate with Maun Suang its inclusion in the guide?
> While being there, an update to the newmaintainer wiki page would
> be nice :
> 1- because it suggests that svn commit access needs ssh which turns
> out to be quite unstable.
"svn switch --relocate" to http://svn.macports.org/repository/
macports, MacOSForge uses http digest auth, no need for ssh/ssl.
> 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.
> - don't use "+" or "-" in variants names because they are "reserved
> words" of the variant mechanism (many ports still use "-" which
> just does not work).
Agreed too, replace all instances of - (as a word separation
character, I'm assuming) with _, and + I just don't know what it's
used for, but it definitely does not belong there! (use _ too?)
> - a port's default variant (including no variant) should usually
> install the full features (except if it looks like madness)
This is a hotly debated topic: should ports be minimalists,
deferring all non-default/basic extensions/functionality to variants?
Or should they instead be all encompassing, providing everything the
package has to offer out of the box? Somewhere in between, per
maintainers' better judgement? I would support the latter, but I am
more than aware that's a very grey area to be in, so I'll let others
with stronger positions venture their opinions.
> - variants should have a description
We should make this a must!
> - platform variants are named "platform" instead of "variant" (many
> ports again)
Agreed too, common mistake that should be corrected.
> - typical names : no_* x11 gtk2 aqua debug server ipv6
Aha, I like common names and people standardizing on them by sheer
practice and/or jurisprudence (gotta love that word!), among other
things that buys us the assurance that "variant cascading" will work
seamlessly (port foo depending on port bar builds with variant baz,
MacPorts will try to build bar with variant baz too if it provides it
-- that fails if foo and bar name the variants differently, a total
waste!). But I fail to understand what you tried to say with your
In any case, common names should be documented in the guide and
anywhere between encouraged and enforced ;-) A settlement on them
also sorta implies an answer to my question above: should ports be
minimalist or fully featured? If 'no_ipv6' becomes a standard
variant, then they are minimalist; if instead 'ipv6' becomes the
standard, then they are fully featured. The middle ground I'd like to
advocate means having, for example, 'ipv6' as a standard and 'no_x11'
as another one.
> - more obscure names should either have a good description or a
> clearer name like with_* / without_* / enable_* / disable_* to at
> least give a clue if we are triggering a dependency or an inner
> mechanism. A good example : disable_utf8mac,
> disable_extra_encodings, enable_cp932fix (libiconv).
Seconding Ryan in his reply to you, I favor simpler and shorter
variant names. In all cases, variant descriptions should do a good
job at explaining what they are about and what they imply with
respect to the build and deps... that is, at explaining them ;-)
More information about the macports-dev