Arch Linux User Repository

@solarisfire these issues were caused because we were using the "latest" release track where Cursor would sometimes publish different binaries but with the same release version.

I have now switched this package to be on the "production" track of Cursor and I expect that this kind of issue will now be avoided in the future.

Also, thanks to a patch from @oech3 we now install the extracted Cursor app and do not execute the original AppImage anymore.

For anyone who want's to contribute a PR, this is the repo: https://github.com/Gunther-Schulz/aur-cursor-bin-updater

If you create a PR please do it against the development branch. Thank you!

electron is excluded (.deb is compressed by tarball twice).

FHS things is upstream's fault. Fixing it might break something more than desktop entry.

1. electronNN does not get added during package(). Appending to arrays inside package() is tricky, you can experiment with it to see what works and what doesn’t. However, for the depends=() array, $_electron is not even defined, so you are appending an empty entry. That’s why .SRCINFO does not contain electronNN and it doesn’t get pulled in during installation.

2. I suggest defining $_electron globally and then checking in prepare() whether the target version matches the actual version. If they don’t match, you can bail out early and ask the user to leave a comment here.

3. The package still launches without electronNN because it uses the bundled Electron. Please decide which one you want to use (system or bundled), but not both. Personally, I see no reason to keep a duplicate copy of Electron, so I recommend using the system version.

4. If you switch to a system-wide Electron, please extract the resources to usr/lib/cursor. Normally, usr/share should not contain executable and/or binary files. Even the VS Code Arch package uses usr/lib, which seems to be also the AUR convention. I highly recommend looking at some packages maintained by @zxp19821005. Most of their packages follow exactly this model, so you could reuse their approach. It may not be the golden standard, but it’s definitely better than the current setup.

Thanks for maintaining!

Gudideline has: Automated PKGBUILD updates are used at your own risk and any malfunctioning accounts and their packages may be removed without prior notice.

Orphaning and switching to different active user would better.

There has been a delete request for this package by @oech3 because of the slow updates and recurring issues with this package.

I am open to transfer this package to someone else or adding a co-maintainer.

Btw, @oech3 I gave you full Collaborator access to the Github repo a while ago already. Feel free to merge any PRs yourself.

@philcauss @oech3 @philcauss it was an unfortunate bug in the update script. should be solved now (one final manual bump however because of updates to the PKGBULD based on the PRs).

@gugah concerning a trigger based update schedule: I am not sure how that could be implemented with Github actions. Do you have any suggestion?

I have now added a testing script that tests the whole Github action workflow locally which should improve the situation for future updates(I may make this part of a CI) : https://github.com/Gunther-Schulz/aur-cursor-bin-updater/blob/main/test_workflow.py

All open PRs have been merged (thank you @oech3 and @madic-creates)

@g.shulz maybe it's better not to let the github-actions bot update the main branch on a fixed schedule and use a trigger instead: https://github.com/Gunther-Schulz/aur-cursor-bin-updater/commits/main/

We're getting spammed with frequent, unnecessary updates.

What's up with the constant pkgrel updates? 5-10 times per version recently.

Please don't update for just bumping pkgrel and do nothing.