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.

Since I have been put in the reviewers, let me add my two cents.

Another case in which using variables in WWW makes sense is for master/slave ports or ports that are very similar (e.g. the GCC ports, which do not follow the master/slave model at least for now, but have indeed very similar Makefiles). Assume for example software foo comes in different versions and we want to point WWW to different urls depending on those versions, we could do something like WWW= https://foo.com/${DISTVERSION}.

IMHO, make -V WWW is the way to go. Whoever has the knowledge to understand a Makefile should be able to use make -V as well.

In D53824#1242870, @salvadore wrote:

Another case in which using variables in WWW makes sense is for master/slave ports or ports that are very similar (e.g. the GCC ports, which do not follow the master/slave model at least for now, but have indeed very similar Makefiles). Assume for example software foo comes in different versions and we want to point WWW to different urls depending on those versions, we could do something like WWW= https://foo.com/${DISTVERSION}.

Of course, the same concept might apply to flavors: it could make sense to have ports associate different WWW for different flavors.

@salvadore wrote:

IMHO, make -V WWW is the way to go.

It is a way to go to obtain the web address programmatically, at the command line, etc., there's no argument about that. We want plain URLs for visual clarity and to be able to click on it in a capable terminal or text editor. I don't want to escape to command prompt to execute xdg-open $(make -V WWW) or write some context-dependent macros when I could just click.

Of course, the same concept might apply to flavors:

Hardly: flavors is a mechanism to build the same program (hence probably same WWW) but in different ways to produce different pile of bits (e.g. against several toolkit versions). Subpackages are more likely to parameterize WWW, but they aren't there yet.

In D53824#1243052, @danfe wrote:

@salvadore wrote:

IMHO, make -V WWW is the way to go.

It is a way to go to obtain the web address programmatically, at the command line, etc., there's no argument about that. We want plain URLs for visual clarity and to be able to click on it in a capable terminal or text editor. I don't want to escape to command prompt to execute xdg-open $(make -V WWW) or write some context-dependent macros when I could just click.

Typing xdg-open $(make -V WWW) took me 1.5 seconds. Reading PORTNAME and PORT VERSION even less. This doesn't seem like a significant argument. I can afford to loose that kind of time out of my life if
it can better facilitate the development and developers of FreeBSD ports. Can't you? :-)

Of course, the same concept might apply to flavors:

Hardly: flavors is a mechanism to build the same program (hence probably same WWW) but in different ways to produce different pile of bits (e.g. against several toolkit versions). Subpackages are more likely to parameterize WWW, but they aren't there yet.

With programmers hat on...
In my opinion this argument is a non-starter.
An *enormous* amount of time has gone into the development
of the "ports framework" to make it more effective and
efficient. It's a brillient piece of work and has largely
succeded. The topic of this review seeks to reverse this
work. If we start here, where does it end? What harm is it?
Well. If you look at the outstanding pr(1)s. You'll see that
there are *thousands* of outstanding bugs. Some over a year old!
Better efficiency would bring this number down substantially.
Making and keeping the ports framework more effictive will also
help in this regard. Neutering it will not. If a user wants to
poke around in something they know little or nothing about, eg;
a Makefile. Then learning what a variable is will be a great
first step. Won't it? If we want to encourage new developers.
How good a developer will they ever be if they're unwilling to
take a little initiative? If we (as programmers/developers) can
make better work of our time here. We can afford ourselves more
time squashing outstanding bugs. I vote to keep and make the
ports framework more efficient.