On Mon, 27 Dec 2021 15:06:44 -0800 Brett Cornwall <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]>
