Created attachment 244013 [details] rustypaste-0.12.0.patch Description: * Remove trailing slash in WWW * Prefer hardcoded strings ChangeLog: https://github.com/orhun/rustypaste/blob/v0.12.0/CHANGELOG.md * Added: - Add an endpoint for retrieving a list of files - Support multiple auth tokens - Add new line character to most prominent messages * Changed: - Bump Shuttle to 0.23.0 - Bump dependencies * Fixed: - Deploy the Shuttle service when a new tag is created QA: * portlint: - WARN: Makefile: possible use of absolute pathname "/var/db/rustypaste". * testport: OK (poudriere: 13.2-RELEASE, amd64, OPENSSL tested)
Hi Jesús, Thanks for the patch. Why switching from PORTNAME to rustypaste? The former is safer. It would be too easy to have a typo in one place when typing rustypaste over and over again.
(In reply to Fernando Apesteguía from comment #1) Hi Fernando, I know the current port works fine, but I think if the port is renamed to something else, probably the upstream repository will not, so the port might break. The same practice I am following for USERS and GROUPS to avoid using arrays that depend on an index. I think it is safer to simply write the actual users and not rely on an index which could break the port.
I have received a portscout notification at this time for this port, as a new version has been released [1]. I will send a new patch. [1] https://github.com/orhun/rustypaste/releases/tag/v0.12.1
(In reply to Jesús Daniel Colmenares Oviedo from comment #2) I'm not sure I follow. Why would we want to rename the port?
(In reply to Fernando Apesteguía from comment #4) I gave submitter the advice that ${PORTNAME} should only be used for strings that vary with the portname. I.e. strings such that when the port is renamed, the port is valid. I don't see the point quite frankly in bulk search-and-replace of the portname with ${PORTNAME}. It doesn't make any sense. E.g. a github repository doesn't care about what we call the port of the project hosted there. There is no reason why its name should be derived from the port name. If you have trouble spelling the project name, that's an issue that should be solved by means other than coupling identifiers that are only related by convention (i.e. that we name the port usually the same as the upstream project) and not because they need to be the same.
Created attachment 244041 [details] rustypaste-0.12.1.patch ChangeLog: https://github.com/orhun/rustypaste/blob/v0.12.1/CHANGELOG.md * Fixed: - Do not list expired files QA: * portlint: - WARN: Makefile: possible use of absolute pathname "/var/db/rustypaste". * testport: OK (poudriere: 13.2-RELEASE, amd64, OPENSSL tested)
(In reply to Robert Clausecker from comment #5) > I don't see the point quite frankly in bulk search-and-replace of the portname with ${PORTNAME}. There wasn't such search-and-replace. AFAICT, this was done directly when creating the port in 31484c7300b6d. > E.g. a github repository doesn't care about what we call the port of the project hosted there. There is no reason why its name should be derived from the port name. Of course a GitHub project doesn't care. We create ports out of GitHub's repositories and not the other way around. I don't really understand what your point is here. You are stating something that is already true in the ports tree. 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. >If you have trouble spelling the project name, that's an issue that should be solved by means other than coupling identifiers that are only related by convention (i.e. that we name the port usually the same as the upstream project) and not because they need to be the same. 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. I think it's a good practice, but at no point it *needs* to be the same, nor the use of PORTNAME forces us to do that. Honestly I don't know what kind of improvement we're trying to achieve here. 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 haven't been provided with any compelling evidence as to why this is a good thing.
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.
(In reply to Robert Clausecker from comment #8) > 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. Strawman fallacy. No need to counter argument this. > 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. This is public record. Maybe we try another language here? Also, you say "each time"? I don't think that's true. Many times? Maybe. I would need to do the math. 212 renames since 2018. If you say "each time" there was a massive pain chasing the use of PORTNAME, ok. I believe you. >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. In that case, let me correct you. You misunderstood. It is not that I am so against that I am not letting the maintainer do anything. That is just plainly false and can not be derived from my words. Please retract. I explicitly say that I don't think this is a good idea. As such, I don't think I am able to commit this and being responsible for the change. Or defend it should any other committer asks why I did those changes.
I'll take it
Hello Jesús: I'll take your PR. Please, could you do some minor modifications to your patch file with the following advices? - Use ${PORTNAME} instead of hardcoded name is fine. I agree with Fernando about it. I don't see critical problems when project is renamed - If you want, you could create RUSTYPASTE_USER/RUSTYPASTE_GROUP and use them at USERS/GROUPS/PLIST_SUB/SUB_LIST. Avoid use of USERS[0]/GROUPS[0] Take on mind if you use variables instead of hardcoded words the port will be easier to apply changes. It was an advice I received long time ago
Created attachment 244062 [details] rustypaste-0.12.1.patch Description: * Add RUSTYPASTE_USER/RUSTYPASTE_GROUP variables * Use POSTNAME instead of a hardcoded string QA: * portlint: - WARN: Makefile: possible use of absolute pathname "/var/db/${PORTNAME}". * testport: OK (poudriere: 13.2-RELEASE, amd64, OPENSSL tested)
(In reply to Jose Alonso Cardenas Marquez from comment #11) Hi Alonso, Thanks for taking this bug. --- A big apology to everyone here, for the noise and for causing a problem.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=a9d4d85bd0dfc064f265e973e009730c0c5d154b commit a9d4d85bd0dfc064f265e973e009730c0c5d154b Author: Jesús Daniel Colmenares Oviedo <DtxdF@disroot.org> AuthorDate: 2023-08-13 21:59:13 +0000 Commit: Jose Alonso Cardenas Marquez <acm@FreeBSD.org> CommitDate: 2023-08-13 22:00:52 +0000 www/rustypaste: Update to 0.12.1 Description: * Remove trailing slash in WWW * Prefer hardcoded strings ChangeLog: https://github.com/orhun/rustypaste/blob/v0.12.0/CHANGELOG.md * Added: - Add an endpoint for retrieving a list of files - Support multiple auth tokens - Add new line character to most prominent messages * Changed: - Bump Shuttle to 0.23.0 - Bump dependencies * Fixed: - Deploy the Shuttle service when a new tag is created PR: 273053 www/rustypaste/Makefile | 18 +-- www/rustypaste/Makefile.crates | 140 ++++++++++---------- www/rustypaste/distinfo | 286 ++++++++++++++++++++--------------------- 3 files changed, 223 insertions(+), 221 deletions(-)
Committed thanks!