Date: Sun, 13 Aug 2023 16:46:08 +0000 From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 273053] www/rustypaste: Update to 0.12.1 Message-ID: <bug-273053-7788-WW6D0fMHUE@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-273053-7788@https.bugs.freebsd.org/bugzilla/> References: <bug-273053-7788@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D273053 --- 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=3Dfoo and we can do WHATEV= ER=3Drustypaste so we again, avoid to type "rustypaste" 11 times in the Mak= efile. 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 a= nd 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 th= ere 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 e= ven 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 sys= tem (referring to Dragonfly's dports) is changed. For "make makeplist", the Porter's Handbook even explicitly warns that you need to carefully check wh= ich 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.=20 > They don't need to be the same. But we try to follow POLA. Meaning it wou= ld be really confusing to create a port out of a project called upstream "s= helloxidizer" (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 po= rt 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.= =20 And each time someone has to go and unfuck brainless bulk-uses of ${PORTNAM= E} and figure out where the port actually needs ${PORTNAME} and where it's jus= t a random occurence of the same string. > I saw you already started changing ports this way, so I'm not opposing, b= ut 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. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-273053-7788-WW6D0fMHUE>