cgi-io: add generic version check override

[stintel]

The binary included in this package does not output anything, causing the generic version check in CI to fail. Override the test.

I've removed all the noise from the PR template since it's not relevant. This works around an unrelated CI failure in #29784.

[stintel]

@BKPepe since you're looking ... can you review this one? I'd like to get this in before #29784 so the checks there become green. TIA.

[BKPepe]

I see, I see.

Look, sure, it makes sense that the package doesn't report its version. However, I'm of the opinion that since we're already touching it, we could make it even better.

I understand this isn't your fault, but while we're at it—and I doubt anyone else will look into this in the future—I would also add a test.sh file. This way, we can test that the package actually works, given that testing it via the version isn't possible.

I think @commodo might be able to advise on that file, or perhaps using Claude AI could help us out too.

[stintel]

So if any executable in a package outputs a version number matching PKG_VERSION, the package is assumed to be working? I'd say that's wishful thinking.

[BKPepe]

You're right about that, and it certainly is, but at the moment it's an improvement over the original state, so let's actually just be glad we have something. :-/ The issue for testing the generic version check had been sitting here for, man, over 5 years and it didn't bother anyone. Of course, it is a really small step and yes, ideally it would be nice to have it covered in more areas. I agree with that, I'm not disputing it at all. That's exactly why I'm suggesting adding the test.sh file, which will test the package more thoroughly. For example, https://github.com/openwrt/packages/blob/250b6f2211127bc2c90b6fa7b3abd9874c0deb89/lang/python/Flask/test.sh looks usable.

[stintel]

What bothers me is that CI for package X turns red due to a broken test on package Y. This is broken and frustrating behaviour. I recently spoke to someone who told me they stopped contributing bumps to (some of) their packages due to this.

For this specific broken CI behaviour I opened openwrt/actions-shared-workflows#121.

As for this PR, it's the minimum effort to work around CI failing on #29784, but also the maximum effort I am willing to spend at this time. If this PR is going to be blocked on "please add a proper test", I will just close it, and maintain what I use in a local branch.

[BKPepe]

I get your frustration, but simply saying 'this is why I stopped contributing' is the easy way out. We can complain that the current state isn't perfect even though it’s steadily improving, but if we all just retreat to our own silos, nothing will ever get fixed.

Look at the sheer volume of packages we have. If we honestly evaluate how many are actually used or up-to-date, we have to admit that a lot of them are essentially dead code. Historically, things were merged just for the sake of adding them, without proper testing across different architectures. Maybe it's time we adopt a stricter deprecation policy and actively prune unmaintained packages instead of carrying that technical debt.

I agree that CI/CD pipelines can sometimes feel like a roadblock, especially for casual contributors. It’s frustrating when you submit a simple fix, only for the build to fail because your update broke a downstream dependency you don't even use. But testing only the updated package and ignoring its reverse dependencies isn't the solution. That just pushes the breakage onto the end users.

Instead of getting frustrated, let's improve our collaboration. If a dependency breaks, open an issue and ping the maintainer. It helps the project and shows the maintainer that their package actually has users.

Open source isn't black and white. It's a shared effort. People moving away from the project isn't caused by us implementing better CI/CD standards. If anything, CI/CD prevents the whole ecosystem from collapsing. Everyone still has the chance to contribute, and working together is the only way forward. Keeping everything maintained in private local forks is a dead end, and we all know it. :)