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

[Yves de Champlain]

Le 07-06-20 à 10:38, Juan Manuel Palacios a écrit :

>
> On Jun 19, 2007, at 7:00 PM, Yves de Champlain wrote:
>
>
>>>
>>> 	I couldn't make it out from your edits, so I'm not sure if the  
>>> devel variant changes the port version number (a big NO-NO!!),  
>>> but even if it doesn't everybody is much better off if you turn  
>>> it (the devel variant) into a different port. Even if for  
>>> consistency with other -devel ports.
>>
>> Um, the fact here is that Etoile is many things (apps, frameworks,  
>> theme engine ...).  The devel variant just builds the whole  
>> package and enables debugging while the novariant builds a reduced  
>> set, targetting only the stable parts of the exact same source  
>> tree.  I won't argue about the consistency, but making two  
>> different ports means that they will overlap with one another and  
>> there is no mechanism in MP about this (except failing on activate).
>>
>> What do you think ?
>
>
> 	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.

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.

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)

- 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).

- a port's default variant (including no variant) should usually  
install the full features (except if it looks like madness)

- variants should have a description

- platform variants are named "platform" instead of "variant" (many  
ports again)

- typical names : no_* x11 gtk2 aqua debug server ipv6

- 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).

yves