[aur-general] Clarification for Deletion request #30701

[Aleksandar Trifunovic]

On Tue, Dec 28, 2021 at 7:46 PM Brett Cornwall via aur-general
<aur-general at lists.archlinux.org> wrote:
>
> 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.

What does a central package management have to do with this
discussion? It is pragmatic that you go around and delete files just
because you like to waste your time and time of other people? Sounds
like you don't understand the word pragmatic. Also a package that
works (upstream binary) is technically correct and repackaging done
with newer libraries is less likely to be technically correct so I
have no idea what you are talking about. This is something that should
be widespread knowledge and accepted shortcoming of the distribution
model and not argued like its perfect.

> I do not accept that containing upstream AUR packages to mirror the entire
> repository of Arch is pragmatic or even helpful.

It is many times repeated that majority of these packages are not the same.

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

I do that and/or try to fix it as well if possible and? Reporting a
bug does not change the fact that the package is broken *now* and
sometimes cant be fixed for a while.

Aleks