Hello Ani, Firstly, I would like to point out that VCS package functionality is rarely found in major repositories. For example, ALT Linux, FreeBSD Ports, Scoop, SlackBuilds, and T2 SDE all use Git tags similarly to how this package is structured. Meanwhile, Nixpkgs and OpenSUSE employ a version+revision approach, where the package is periodically updated to a newer commit. I am unsure how you expect non-AUR users to always have access to the latest build.
Secondly, I want to reiterate that updating the version of a VCS package without any changes to the build process is against the rules. While it is technically possible, it violates AUR guidelines. Another issue with VCS packages is their poor integration with AUR helpers. Even if a user manually requests a rebuild (e.g., with yay -S rpcs3-git), yay will update pkgver but will skip the build, silently installing an older cached version under a misleading new pkgver. This only makes the matters worse, as you will receive bug reports from outdated versions misidentified as the latest. Furthermore, as I have already explained with the LuaJIT example, official Arch repositories (core, extra, etc.) do not support VCS packages. If this package were ever to gain enough popularity for inclusion in the official repositories, there would be no option to build the latest commit directly. The only alternative would be to explicitly inform users that the official Arch package is, in fact, unofficial and that they must install aur/rpcs3-git, forcing them to: 1. Trust an unsigned script from an unknown third party, 2. Install an extensive toolchain (several gigabytes in size) just to compile the package locally, 3. Maintain a stable internet connection to avoid failures during multiple git clone operations, 4. Spend significant time compiling the package, 5. Potentially encounter build errors due to the instability of VCS packages, 6. Possibly discover that a newer commit was published before their build even completed, 7. Realize that their bug reports may be of little value due to the inherent non-reproducibility of VCS packages. If you plan to contact all distributions currently packaging RPCS3 this way to enforce your versioning scheme, I would like to reiterate my proposed solution: periodic version bumps. I have not seen any direct counterarguments to this approach, and if you already have an automated system for triggering updates, I do not see why this would be an issue. As long as there are no changes to .gitmodules dependencies, new versions could be released automatically without manual intervention. Even if adjustments were required, modifying the PKGBUILD would be trivial. On a side note, there is a reason why most widely adopted software projects maintain multiple branches and restrict bug reports from stable releases. As long as new commits are pushed faster than the project can be rebuilt, a rolling-release package will inevitably lag behind the latest development state. Best regards, Vitalii On Wed, Feb 26, 2025 at 5:57 PM Annie Leonhardt <[email protected]> wrote: > Hello, > > Thank you for your reply. > > We can bump the AUR version should we need to push a protocol update, for > example. And even then, users can still trigger an AUR update on their side > if they see it's outdated and they need something from newer. > > We are not interested in bug reports on old builds, as we do not accept > those, only the latest build is supported. > > We tend to break master branch every so often, and we can quickly remove > builds from our updater to prevent regressions from spreading. The updater > then updates to the last good build. And again, we can quickly push a > version update to the git version if we want users to get explicitly > prompted for update. With arbitrary version bumps, there is no way to tell > if a version is good or not. > > Furthermore, we are already receiving support requests from people on this > AUR because it's outdated, and we do not want to have these. > > A version of this AUR existed in the past, but due to the same reasons we > also asked for it to be removed. > > Best Regards, > Ani > ------------------------------ > *From:* Vitalii Kuzhdin <[email protected]> > *Sent:* Sunday, February 16, 2025 8:14 PM > *To:* [email protected] <[email protected]> > *Cc:* [email protected] <[email protected]>; > [email protected] <[email protected]> > *Subject:* Re: [PRQ#70009] Deletion Request for rpcs3 > > Greetings, > > Thank you for bringing the rolling version scheme to my attention, I > wasn't aware of this. > > I understand the concerns about outdated builds being misleading. However, > I believe there may still be value in maintaining this package with some > modifications. > > As you already know, VCS and regular packages have differences beyond the > pkgver() function. For example, the AUR guidelines for VCS packages suggest > version bumps only when the build process changes, as pkgver() handles > version updates otherwise. However, if the version is not changed on the > AUR, users may miss notifications about new commits and important updates. > AUR helpers (at least mainstream ones I am aware of) don't automatically > watch the repo for changes. Without manual rebuild requests, users won't > receive automatic updates, potentially leading to RPCN-related issues > you've mentioned. > > Additionally, VCS packages lack reproducibility. Given RPCS3's extensive > dependency chain, this could make bug tracking significantly more > challenging. > > Many rolling release software packages exist in the official Arch repos > (e.g., LuaJIT). Since official repos don't allow VCS packages, the solution > is regular version bumps. As a compromise, I propose committing to, say, > weekly version updates for the RPCS3 package. > > I'm open to further discussion, but if it is still not useful to keep > this, I understand you obviously do not want to get bug reports coming from > an outdated package. Thank you for the seriously impressive work behind the > emulator. > > Best regards, > > Vitalii > > On Sun, Feb 16, 2025 at 8:27 PM <[email protected]> wrote: > > AniLeo [1] filed a deletion request for rpcs3 [2]: > > Please read our release notes at > https://github.com/RPCS3/rpcs3/releases/ and remove this AUR. > > This AUR is misleading, offering outdated builds as if they were some > kind of RPCS3 stable builds, such a thing does not exist. It is > offering a random outdated build that had no special quality control > whatsoever compared to every other build. > > I leave a copy of the relevant line from our release notes below, just > in case: > > "Note: These are NOT stable builds. RPCS3 is a rolling release > software without stable builds. These are random tags we do from time > to time. Do NOT use the branch from these tags to package RPCS3." > > --- > > Verification that I am a member of the RPCS3 team and am formally > requesting for this AUR to be removed: > https://forums.rpcs3.net/showthread.php?tid=208697&pid=328170#pid328170 > > [1] https://aur.archlinux.org/account/AniLeo/ > [2] https://aur.archlinux.org/pkgbase/rpcs3/ > >
