[aur-general] Clarification for Deletion request #30701

Aleksandar Trifunovic akstrfn at gmail.com
Tue Dec 28 18:07:23 UTC 2021


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.

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

Best,
Aleks


More information about the aur-general mailing list