Binary AUR packages when associated packages exist in the repos
I would like to reopen the discussion to delete a package (yuzu-mainline-bin) that exists in [community] (yuzu). As per AUR guidelines [1]:
The submitted PKGBUILDs must not build applications already in any of the official binary repositories under any circumstances. Check the official package database for the package. If any version of it exists, do not submit the package. If the official package is out-of-date, flag it as such. If the official package is broken or is lacking a feature, then please file a bug report.
Exception to this strict rule may only be packages having extra features enabled and/or patches in comparison to the official ones. In such an occasion the pkgname should be different to express that difference. For example, a package for GNU screen containing the sidebar patch could be named screen-sidebar. Additionally the provides=('screen') array should be used in order to avoid conflicts with the official package.
yuzu-mainline-bin provides zero extra features or functionality compared to the repo build, at least, no one has yet mentioned such. The name itself refers to yuzu-mainline which is exactly what the repo package is building. As a result I filed a deletion request, but this was apparently rejected [2] with the reasoning that "Yuzu only seems to support binaries", along with some links to comments from upstream as well as a link to a previous thread [3] on the ML from 2021 where this topic was mentioned before. The other point mentioned in the AUR package comments [4] is that the repo version can be out of date frequently. Again, that is addressed in the quote above, still doesn't justify the AUR package. To me, the entire purpose of having the official repos is to have binary builds (presumably done in a clean environment with some minimal source verification), so we don't have to rely on arbitrary developers to have clean environments and only really need to trust the TUs who build that package. If there are issues with a package, they are first reported to Arch maintainers via bug report (this is in accordance with the "please file a bug report" in the quoted passage above). This applies to any package, and yuzu is neither an exception nor special case here. Also the entire point of having distros in the first place is that you have someone (who is usually not upstream) maintaining the package and making sure it slots well into your system. I don't know of any package in any distro where the distro builds the package, but upstream is expected to support it. So why should a specific -bin package exist in the AUR just because upstream is in accordance with decades of tradition? Either way they clearly do not want unnecessary bug reports from inexperienced users [5], so any Arch user reporting a bug with the repo package upstream would be unhelpful to both Arch and Yuzu. Best, éclairevoyant [1] https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submissi... [2] https://lists.archlinux.org/archives/list/aur-requests@lists.archlinux.org/m... [3] https://lists.archlinux.org/pipermail/aur-dev/2021-December/005056.html [4] https://aur.archlinux.org/packages/yuzu-mainline-bin#comment-913540 [5] https://github.com/yuzu-emu/yuzu/blob/master/.github/ISSUE_TEMPLATE/bug_repo...
I would like to reopen the discussion to delete a package (yuzu-mainline-bin) that exists in [community] (yuzu). […] The community/yuzu package is built from sources, while the yuzu-mainline-bin PKGBUILD offered in AUR is wrapping the official upstream build.
To me this falls under the “extra features” exception. Being the official upstream binary is an important feature not present in source-built version found in Arch’s package. At a quick glance it also seems to me, that the AUR version offers telemetry and Discord integration,⁽¹⁾ while the Arch version doesn’t.⁽²⁾ ____ ⁽¹⁾ https://github.com/yuzu-emu/yuzu-mainline/blob/4d3e47ba39141bd703d7ca48eb448... ⁽²⁾ https://github.com/archlinux/svntogit-community/blob/db4c84fe5f80fb09b29d2ef...
Hello, Just a little note, the reason I imagine that the discord integration and telemetry is not compiled into the official repo build is because most people wouldn't want an application tracking them. So the AUR package would very rarely be used... Have a good day, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@polarian.dev
Hi Polarian.
Some people would like discord integration, and as for telemetry quite a
large segment of the computer-using population do not mind providing
telemetry at all.
Just look at the amount of windows users out there. :P Now whether that is
out of ignorance or a conscious choice is the subject matter of quite a
different discussion.
I'm with mpan on this one, his package provides a version of yuzu with
features that is not available in the mainline. In essence, it provides a
choice, which is what open source is ultimately about?
Which package to use is then up to the user, as it should be, and the
default is the one in mainline.
Why is having this package in the AUR a problem? I struggle to understand.
Kind regards,
Evert Vorster
On Fri, 12 May 2023 at 10:54, Polarian
Hello,
Just a little note, the reason I imagine that the discord integration and telemetry is not compiled into the official repo build is because most people wouldn't want an application tracking them.
So the AUR package would very rarely be used...
Have a good day, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@polarian.dev
At a quick glance it also seems to me, that the AUR version offers telemetry and Discord integration,⁽¹⁾ while the Arch version doesn’t
Thanks for pointing this out. Then the yuzu-mainline-bin AUR package should continue to exist.
The community/yuzu package is built from sources, while the yuzu-mainline-bin PKGBUILD offered in AUR is wrapping the official upstream build.
To me this falls under the “extra features” exception. Being the official upstream binary is an important feature not present in source-built version found in Arch’s package.
This I simply cannot agree with. Is upstream sprinkling magic dust on their build server? There is no inherent feature present based on who types the compilation commands. The only possible exception would be for non-open source software (like visual studio code) or cases (like yuzu) where the flags actually differ. But if the flags/environment are the same, and the only difference is using stuff like bundled vs system libraries, I can't agree. If system vs bundled libs is a substantial difference, then why even have distros? The whole point of having distros is making the packages play nice with each other. If you want the bundled version you can just download directly from the release page. But if the Arch PMs/community disagree with me, then I think this should be explicitly specified on the wiki as a separate exception, i.e. "-bin (upstream binary release) versions of packages in the official repos are also permitted in the AUR, since they are officially supported upstream (unlike the repo packages)." Otherwise we have conflicting messages when one PM deletes -bin packages and another doesn't. And it helps us as users not have to spend time guessing whether a package should exist or not and defending its existence, we can just point to the wiki. Best, éclairevoyant
participants (4)
-
Evert Vorster
-
mpan
-
Polarian
-
é