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.
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.
signature.asc
Description: PGP signature
