(zotero) Package is 32-bit only, but 64-bit application/installer is available

[teknowledgist]

Checklist

• I have verified that this is the correct repository, and the package is maintained by the chocolatey-community user.
• I have verified that this is happening in the latest available version of the package.

Chocolatey Version

2.3.0

Chocolatey License

None

Package Version

7.0 - 7.0.3

Current Behaviour

The 32-bit version of Zotero installs on 64-bit systems, but since v7.0, there has been a 64-bit version available. Also, the 32-bit install of the application recognizes that it is on a 64-bit system and pops up a notice informing the user that the 64-bit version would be more efficient.

Expected Behaviour

The 64-bit version would install on 64-bit systems (absent forcing the 32-bit install).

Steps To Reproduce

1. On a 64-bit operating system, run choco install zotero or if a pre-v7 Zotero is already installed, run choco upgrade zotero.
2. Observe that Zotero is installed in the Program Files (x86) directory and/or run Zotero and a notice will appear about running 32-bit version on a 64-bit system.
   

Environment

* Windows 11 (23H1)
* Powershell (v5?)

Chocolatey Log

The log is unnecessary because it does not report an error.  The package is embedded and only contains the "win32" installer and the `chocolateyinstall.ps1` clearly only installs that.

Anything else?

No response

[hkdemiralp]

Zotero version 7.0.5 in chocolatey repo is still 32 bit. Switching to 64bit is seamless. Only a URL change in the choco package is enough to install 64 bit version. I had reported this at community discussions #2522 and package repo before. I hope it is updated soon.

[pauby]

@hkdemiralp This is a community repository. There is no one person responsible for the package in here. Pull requests are welcome.

[teknowledgist]

I have made a pull request.

Note: I don't have ready access to the official test environment, so someone else will need to test against that if it is absolutely required before merging. I see no reason to think that the changes might break what has already been working in the test environment, but I suppose those are famous last words.

[pauby]

@teknowledgist thanks for creating the PR. Running through the test-environment is always required before merging a PR.

[teknowledgist]

So... Hypothetically, I could claim that the package was run through the test-environment and there is no means of proving that I did, right? Would my word be good enough for the PR to then move to the next step (merging or visual review?)?

I suppose the next question is whether I (as the PR constructor) need to be the one to run it through the test environment (or claim so). Could someone else merge the PR into their own repository and report that it worked? And who is to say they did anything different than the hypothetical above?

Is there some kind of "signature" output in the test environment that proves a package was attempted?

[pauby]

So... Hypothetically, I could claim that the package was run through the test-environment and there is no means of proving that I did, right? Would my word be good enough for the PR to then move to the next step (merging or visual review?)?

Of course you could. We work on respect and trust. So when we find you're saying one thing and doing another, that respect and trust disappears which in the team world has consequences (people less willing to review PR's, more scrutiny etc.).

I suppose the next question is whether I (as the PR constructor) need to be the one to run it through the test environment (or claim so).

You don't know if it works in the test environment unless you do, so yes. The test environment is what the Chocolatey Community Repository uses so it's the baseline for this repository as a result.

Could someone else merge the PR into their own repository and report that it worked?

Yes. But at that point you're relying on others to do what you have been asked to do. So that takes willingness and time. See above about respect and trust.

And who is to say they did anything different than the hypothetical above?

You're missing the point. There is a standard that is expected when you submit a PR. It's a standard that is set for many reasons but the TL;DR is it comes down to experience if working on PR's over the years, refining the process and saves time for others. If you're not willing to respect that and work within the rules that have been sat, I'd respectfully ask you not to submit a PR at all.

Is there some kind of "signature" output in the test environment that proves a package was attempted?

No. See above about respect and trust.

[teknowledgist]

I do get the point, truly. I have not and would not do that (even though I'm a bit frustrated). Just because I see gaps in the fence doesn't mean I squeeze through them. 😄 In fact, I've literally been the guy trying to shore-up/hide gaps I've stumbled on with scrap wire and brush to diminish unscrupulous use.

I apologize if my impatience caused any consternation. It's just going to be awhile until I can attempt a run through a test-environment. (Would a different maintainer with a functioning test-environment be able to re-create/steal the changes and submit them as a different PR with a genuine testing claim? Would that be made any easier if I withdrew my PR -- if that is even possible?)

[teknowledgist]

As luck would have it, I got an opportunity to load up the official test environment and was able to test the Zotero package. I ran the updater on my fork, so it isn't v7.0.5, but v7.0.7. Hopefully that doesn't matter for this. I even have proof! 😄

The uninstall also worked, but I did that after the screen capture. The chocolateyuninstall.ps1 file wasn't substantively or functionally changed, so I doubt you need proof of that working.

Let me know if I can do anything else.