sysutils/bsdstats: Update to 7.1

[salvadore]

Summary

Bugfix: Change [ -f %%PREFIX%%/etc/bsdstats.conf -a ...] into [-f %%PREFIX%%/etc/bsdstats.conf ] && [ ... ] so that the second condition is tested only if the first one is true: thus we avoid errors in the second condition in case %%PREFIX%%/etc/bsdstats.conf does not exist.

Submitted by: [e-mail] (maintainer)

[tcberner]

head/sysutils/bsdstats/files/300.statistics.in

395

^ why is there a string comparison, could you not check grep's return value to see if there was a hit or not?

[salvadore]

head/sysutils/bsdstats/files/300.statistics.in

395

To be honest, I wondered the same thing, but did not ask scrappy and assumed that if he was doing such a strange thing he had a reason. I am going to ask him.

[salvadore]

head/sysutils/bsdstats/files/300.statistics.in

395

I am also going to ask him if /usr/local shouldn't be a %%PREFIX%% as well. I think it should.

[gerald]

Lorenzo, I just realized this one's still open. What next steps would you like to take?

[salvadore]

Actually, I have recently looked again at this old review too. Two days ago I have mailed the maintainer and asked him if the patch is still relevant and if he could address the comments in this review. Then of course I am going to proceed consistent with his reply.

[salvadore]

I have not received any reply to my mail and more than a month has passed. I abandon the revision. We can always re-open it or create a new one if necessary.

[gerald]

In D25296#809250, @salvadore wrote:

I have not received any reply to my mail and more than a month has passed. I abandon the revision.

This then looks like a case where you can apply maintainer timeout, Lorenzo. This might be better.

[salvadore]

Bsdstats is a very special port and I prefer not to touch it without scrappy's explicit approval on every single change as:

• the port is not a usual port with one or more distfiles: it has 0 distfiles. The software is developped directly into the port, by scrappy himself;
• the port interacts with a website, which -- if nothing has changed -- is maintained by scrappy himself;
• the patch was created by scrappy himself for reasons that scrappy knows. He explained them to me so that I could manage to write this review's summary, but I have no idea how the software works and if it still makes sense, after a few years to apply the patch;
• in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251504 , scrappy replies in 2021 to a bug report that seems related to this patch that he tested the port and he cannot reproduce the bug: this is after this patch proposal, but it has not been committed. @swills also proposes there a similar patch; the original reporter does not give feedback about still encountering the bug or not;
• a few commits happened since the patch was created, so the software has changed at least slightly; the website might also have changed in the meantime and I have no idea if the patch is still useful for something.

If you really want to apply maintainer timeout, I would rather apply it to deprecate the port (not even removing maintainership and offering it to someone else, as scrappy is the software and website author; if I remember correctly the website code is not opensource, so it cannot be read by anyone, and of course it cannot be modified either: a completely new website should be created). We can add the following timeouts, to get to three:

• https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258035
• https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258036

It is also true that the patch looks very simple and does not seems as something that could break anything, but still... Since maintainer timeout cannot be applied to the website as well, I think port deprecation is more appropriate, if we want to do something about it.