[aur-general] Clarification for Deletion request #30701

[Brett Cornwall]

On 2021-12-28 19:07, Aleksandar Trifunovic via aur-general wrote:
>On Tue, Dec 28, 2021 at 6:21 PM Brett Cornwall via aur-general
><aur-general at lists.archlinux.org> wrote:
>>
>> On 2021-12-28 15:35, alad wrote:
>> >> And how am I supposed to have known that?
>> >>
>> >By looking at how the packages differ before simply accepting the request?
>>
>> I'm not going to compare binaries for each -bin request in the hopes
>> that there's some difference that makes it worthwhile to keep. It's the
>> packager's job to describe what the package's use is; That's what the
>> description field is for. telegram-desktop-bin's *only* message was that
>> it was built by upstream and nothing more.
>
>Following the list I get an impression that "built by upstream" ==
>"packaged by arch". However these packages are practically *always*
>different if the developers are not using/targeting archlinux as
>primary distro. For example cura package was broken in Arch under KDE
>(maybe still is) but the cura-appimage-bin package that is "built by
>upstream" works.

Sounds like a good opportunity to file some bug reports.

>> Again, if someone wants that package without the deps,
>> telegram-no-pipewire or telegram-minimal is a better option.
>>
>> >> 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.
>>
>> Feel free to post an RFC. In the meantime, I'll continue to follow the
>> rules that have been established.
>
>Some rules don't make sense.

That's what the RFC process is for.

>Arch's reality is that the libraries will
>often be newer than the ones the upstream is using for the development
>which can cause subtle bugs.
>
>AUR packages that just repackage upstream bin files have worked for me
>on numerous occasions when Arch packages break. Sure I can download
>the bin package and use it however its nice to have it managed with
>pacman.

Consider using a different distribution if the concept of a central 
package manager does not serve you. This distribution does not cater to 
user convenience; it caters to technical correctness and pragmatism. I 
do not accept that containing upstream AUR packages to mirror the entire 
repository of Arch is pragmatic or even helpful.

If a package is not working for you, the expectation is that you will 
notify the package maintainer of any package-specific bugs or upstream 
if it's a general bug.