As the sentence says "should", it's an advice, which means, it's not enforcable, so, it's just more text that do not really add any no value.

I like this, removes a minor annoyance from working with some ports.

I am in general not a huge fan of using PORTNAME all over the place. It should only be used in places where the port would still work fine if PORTNAME is changed, not in every place where the string PORTNAME expands to appears. But that's another debate.

I was involved in the discussion on the mailing list and while I am a proponent of allowing the variable in the WWW.
In the end we're only ever talking about the difference of some half a dozen characters. So not a big deal either way.
If this should ever be documented as a MUST. I'd like to suggest the use of the terms:
"string literal" and "string variable" as opposed to "literal text". As both a variable AND a literal are still after all,
"literally text". :-)

In D53824#1229914, @portmaster_BSDforge.com wrote:

I'd like to suggest the use of the terms:
"string literal" and "string variable" as opposed to "literal text". As both a variable AND a literal are still after all,
"literally text". :-)

Thank you, that word choice is the correct answer!

@mat wrote:

The ports tree is to be used by developers, not end users. End users have packages and should not have to interact with the ports tree ever.

Yet there are plenty of users who prefer to work with the ports tree for various reasons and CBA to setup a local repo.

If a developer needs to know the actual value, they can run make -V WWW

They can (and do), but it's often easier and faster to simply click the link while editing the file and let either your editor or terminal emulator open it for you.

In D53824#1231777, @mat wrote:

Using must is a no.
This rule should not be absolute.

Sorry, Mathieu. I misread your first review. However,

You can advise people to not put a variable, but variables may need to happen from time to time.

the WWW has been plain URL in the pkg-descr for two decades. AFAIK, it was moved to Makefile to ease processing, not due to necessity of using variables inside URL.
So is there a strong demand for variables in the WWW when it's explicitly set in the port Makefile? Any good example?
The only example, i.e. for keeping WWW and PORTNAME synchronized, is a weak argument to me.

End users have packages and should not have to interact with the ports tree ever.

I agree. On the other hand, the ports tree is a great and prominent feature of FreeBSD.
I believe we should not make it harder for users to interact with the ports, if we want more developers in the future.

we could even add a few targets, like make open-www that would do stuff like xdg-open "${WWW}".

Great idea!

Now, back to the patch. Besides for developer- and user-friendliness, I'd prefer to disallow mangling the URL for security reasons.
If you think that security concerns are exaggerated or there is other reasons to not force clean URL, I'm opened to correct the wording.

In D53824#1231777, @mat wrote:

You can advise people to not put a variable, but variables may need to happen from time to time.

I can't think of any case where that would be true, but I'm always in favor of giving developers more options rather than fewer.

The ports tree is to be used by developpers, not end users. End users have packages and should not have to interact with the ports tree ever.

Mat, you know I think the world of you, but every word in there makes my skin crawl. My customers are the end-users, not the package builders.