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@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.
