On 12/31/20 9:05 AM, Haochen Tong wrote:
On Thu, 2020-12-31 at 07:22 -0500, Eli Schwartz wrote:
You will NOT be permitted to use the name "pipewire-nightly" for this purpose.
... even if I manage to update this package strictly once every day? :- )
Ignoring this facetious comment.
The sole reason for my deletion request is precisely, as the deletion request stated, the fact that it reuses "-nightly" (something that refers to the release cadence, like -git does), when the difference is not in fact due to the release cadence.
Think about this:
if a user searches the AUR and sees: - pipewire-git - pipewire-nightly which one do they choose to install... AND WHY?
I agree -nightly might not be the best choice, but that's a compromise, since 1) -git is already taken but it comes with suprise, and 2) it uses the same option as the official pipewire package so I don't think I should use anything like pipewire-official-git, and 3) most AUR helpers consider -nightly packages to be VCS ones and updates them automatically.
I don't acknowledge the "compromise" of using a name you know is confusing, merely due to your inability to get your preferred name. You can't just *ignore* all criticism about the name by saying "well, I wanted it to be short and simple and I had no choice, don't look at me, nothing is my fault". The fact that nightly *in common with VCS* is assumed to be "development" editions and AU helpers auto-update them with a --devel flag (not a --vcs flag, mind you), is not justification to upload a package with false messaging; once again, pipewire-gstreamer-git would fulfill this criteria.
(Keep in mind not only does pipewire-nightly not mention gstreamer in the pkgname, it also didn't mention it in the pkgdesc. The discoverability level is/was 0%.)
Because I don't think I need to do that. Reason below.
I have no problems with you re-uploading the exact same package, but naming it "pipewire-gstreamer-git" for example. Because then it is obvious from the pkgname what it does!!
It is *okay* for users to upload variant packages that build the same software but with different options from the default version of the package. They just need to be named sensibly.
It isn't specifically about enabling gstreamer, it's the same PipeWire people would expect from [community]/pipewire but more recent. By this logic I would argue that the current pipewire-git should be renamed to pipewire-gstfree-git because it didn't mention its lack of gstreamer support, and people looking to try out the latest PipeWire aren't expecting something incomplete which may silently break their system.
So you think you "don't need to" elucidate the difference between your package, and the package that came first (several years ago), because "my package is better, therefore I don't need to describe why"? If there are two packages, they MUST provide some method of distinguishing between them to the average user. As the one that came second, it falls to you by default, to clarify things to users -- and to justify the package's continued existence as not being a duplicate. The only reason I even know it's different under the hood is because I acquired privileged information first; it wasn't obvious at all. Your basic approach here seems to be "I think the other maintainer sucks at maintaining, therefore I can do whatever I feel like and if anyone is confused, it's the other maintainer's fault for sucking at being a maintainer". The only thing you're convincing me of, here, is that maybe I shouldn't trust you in the future, period. Is your insistence that rules don't apply to you, indicative of some deep-seated desire to experience an account suspension? (Please say "no"... and please make your actions say "no" too...)
I already pointed this out to you last night on IRC, after you asked me about the deletion:
05:58 PM <elibrokeit> hexchain: have you considered that it's entirely not ok to have two packages, one named "pipewire-git" and one named "pipewire-nightly", which build the exact same version of the code and differ only in whether or not they have a gstreamer subpackage? Regardless, there has been discussion in #archlinux-aur about this. My advice was to create a "gst-plugin-pipewire-git" PKGBUILD that configures pipewire, then runs `ninja 05:58 PM <elibrokeit> libgstpipewire.so` to build the one file, then installs it manually. It would depend on pipewire-git=$pkgver to ensure the same commit is used for pipewire and for the gst plugin, and you could install the disputed pipewire-git package + the new package. 05:59 PM <elibrokeit> And again, the only problem I have here is your terrible pkgname habit making it impossible for aur users to know which package to install
Thanks for the reminder, I didn't catch this for some reason. However in my opinion this is too much hassle for both maintainer and users. I still think the best thing for users would be to install pipewire- whatever and still expect a fully working system.
I don't even understand this. If I install "pipewire-nightly", a well-behaved AUR helper would *build* gst-plugin-pipewire-nightly, but not install it, so according to your logic, I would not have a working system. If I did $ aurhelper -Syu pipewire-nightly gst-plugin-pipewire-nightly then and only then would I have a "fully working system" with the latter package actually installed. This works just as well, if they are two different PKGBUILDs. I guess it takes 30 seconds more due to running makepkg twice instead of looking up a cached *.pkg.tar.zst file. ... It is true it is more hassle for the maintainer. (Although I really do not think it is much hassle.) But the pipewire-git maintainer has been maintaining it since long before gnome-shell depended on gst-plugin-pipewire, and no one ever complained until very recently -- I guess it's a shame no gnome-shell users bothered to upload pipewire-git first, merely complain about someone else's work years later. I'm not convinced that we should be in the business of taking packages away from maintainers that are stubborn and don't like or use a particular feature they disable... especially given the feature is a trivially self-contained subpackage that could be built on its own. I'd prefer to reserve "moderator takes your package away" for things where it's a bit less subjective that the package is wrong. Fighting over enabled features is pretty meh. I'm willing to be persuaded otherwise by my fellow TUs. But then in that case, the solution will still not be "upload packages whose names lie about what they are, so that there are *two* canonical generic versions of the package, oxymoron intended", the solution will be "successfully convince the TUs that the single canonical generic version of the package should be the one that internally does XYZ" followed by a handover of the package. -- Eli Schwartz Bug Wrangler and Trusted User