On Mon, 27 Dec 2021 15:06:44 -0800 Brett Cornwall <ainola@archlinux.org> wrote:
On 2021-12-27 23:26, alad via aur-general wrote:
On Fri, 17 Dec 2021 07:01:08 -0800 Brett Cornwall via aur-general <aur-general@lists.archlinux.org> wrote:
On 2021-12-17 09:54, Filipe Laíns via aur-general wrote:
On Fri, 2021-12-17 at 00:17 +0100, Justin Kromlinger via aur-general wrote:
On Fri, 17 Dec 2021 01:05:19 +0200 silentnoodle via aur-general <aur-general@lists.archlinux.org> wrote:
hey all,
Today a package i co maintain (telegram-desktop-bin) was deleted because "Package exists in official community repo", but since we used prebuilt binary as source I did not think that would have applied.
So guess I'd just like a word on what the first point in the rules of submission means: https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submissi...
Cheers, Ben a.k.a silentnoodle
So basically: * telegram-desktop in community is git release 3.3.0 build by Arch Maintainers * telegram-desktop-bin in AUR is git release 3.3.0 build by upstream
For the end user, those two are basically the same package. Therefore the AUR package is a duplicate.
No, they aren't. I haven't looked into the request but if this is indeed the case, the package was incorrectly deleted.
From the rules of submission [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.
Submitting a package that is only different from the technicality that someone else built it is not enough to warrant its own package. If there's an issue with the telegram package in the repos, users should submit a bug report.
As it stands, there was nothing notated in the package to suggest that it was anything but an upstream binary, so that was why I deleted it.
[1] https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submissi...
The upstream build is vastly different from the repos. Besides lacking bugs in the downstream version, it only has a fraction of the dependencies (i.e. no pipewire). As such I see no valid reason for the deletion.
And how am I supposed to have known that?
By looking at how the packages differ before simply accepting the request?
It sounds like someone could merely make e.g. telegram-no-pipewire package that builds with the respective flags. Is "it's built by upstream" reason enough to break the rules of submission quoted above?
More broadly, are we to allow all upstream binaries to be packaged? If so, can we designate a different suffix than -bin so that I don't draw ire when I dare accept the removal request of a package with no difference in denotation than the in-repo packages? Or can we get in writing the acceptance of AUR packages of "upstream" releases alongside our own official packages?
As it stands, I am getting feedback both ways: One side is in agreement with me that -bin packages needn't exist and that no, "but it's upstream" is not a valid reason. But the other side screams loudly when *their* favorite upstream package is removed in accordance to that (and never any other time).
I am general disagreement of people widely removing packages from the AUR, merely because it is an upstream build (built on different machines, with different purposes). Even popular packages like firefox-bin have been deleted because of this. If a different suffix will avoid these kind of knee-jerk responses, I'm all for it. -- alad <alad@archlinux.org>