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