[Bug 273053] www/rustypaste: Update to 0.12.1

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273053

--- Comment #8 from Robert Clausecker <fuz@FreeBSD.org> ---
I agree that this is a matter of opinion.

> If we rename this port to "foo", then PORTNAME=foo and we can do WHATEVER=rustypaste so we again, avoid to type "rustypaste" 11 times in the Makefile. Get it right once, and you're done. Using PORTNAME in this case is a matter of convenience, nothing to do with coupling.

No, that's not what happens.  I've had the case of port renames before and it
can be quite annoying to take the handful of ${PORTNAME} used in the port and
decide for each one whether it really refers to the port's name or whether it
was just a "oh the port name appears here, let's use ${PORTNAME}."  Half of
them go one way, half the other.  Gets old really quickly, especially if there
is no easy way to test this.

Thinking this through further, we don't blindly replace all mentions of
freebsd, FreeBSD, or fbsd with ${OPSYS} or "gcc" with ${COMPILER_TYPE} or even
worse, with ${CC} either.  For each such case, a decision is made based on
whether the string actually changes when the compiler type or operating system
(referring to Dragonfly's dports) is changed.  For "make makeplist", the
Porter's Handbook even explicitly warns that you need to carefully check which
replacements of tokens make sense and which don't lest you generate a broken
pack list.  So not sure why people keep bulk replacing ever occurence of the
port name with ${PORTNAME} regardless of whether it makes sense or not. 

> They don't need to be the same. But we try to follow POLA. Meaning it would be really confusing to create a port out of a project called upstream "shelloxidizer" (I'm making this up) and naming it "foobar" in the ports tree.

A common case is when there already is a port with that name or when the port
is renamed because upstream changed the project name or when a copy of the port
is made for a specific major version.  Lots of reasons why ports are moved. 
And each time someone has to go and unfuck brainless bulk-uses of ${PORTNAME}
and figure out where the port actually needs ${PORTNAME} and where it's just a
random occurence of the same string.

> I saw you already started changing ports this way, so I'm not opposing, but I will not commit this since I don't agree with the changes.

I understand that you are so much against this change that you refuse to let
the maintainer change the port he agreed to maintain in this way.  I did not
have any part in this patch in particular.

-- 
You are receiving this mail because:
You are the assignee for the bug.