[aur-general] Clarification for Deletion request #30701

[alad]

On Mon, 27 Dec 2021 15:06:44 -0800
Brett Cornwall <ainola at 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 at 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 at 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_submission
> >> >> >
> >> >> > 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_submission
> >
> >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 at archlinux.org>