On 12/31/20 4:56 AM, Haochen Tong wrote:

On Wed, 2020-12-30 at 20:41 +0000, notify@aur.archlinux.org wrote:

...

eschwartz [1] filed a deletion request for pipewire-nightly [2]:

duplicate of pipewire-git, renamed to "nightly" even though it is not in fact based on "nightly" snapshots but "minutely" or even "secondly" git HEAD.

Purpose seems to be to build pipewire-git with different options...

Hi Eli,

You are not wrong. It is basically -git, but with the same options as the [community]/pipewire package. The reason for the name "-nightly" is really just 1) -git is already taken, and 2) most AUR helpers consider "-nightly" as VCS packages.

As for "why do we need another one apart from -git", it is because the maintainer of -git seems to have some strong opinion on gstreamer and decide to exclude the gst plugin from the package, which I believe gnome-shell depends on. Due to this discrepancy with the official package and the maintainer refusing to do anything, people have sent multiple requests in the past trying to "free" -git, but they were all rejected.

I don't want to argue whether it is preferred/allowed for him to do so (especially with such a good package name :-), so I decided to create this new package for brave people to test this new piece of software without hassle. It tries to follow the official one closely, with occasionally modifications when upstream introduces changes that requires packaging attention.

I hope you can reconsider and probably reverse this decision.

You will NOT be permitted to use the name "pipewire-nightly" for this purpose. 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? (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%.) 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. ... 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 -- Eli Schwartz Bug Wrangler and Trusted User

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

On 1/1/21 8:05 AM, Haochen Tong wrote:

I never denied that -nightly was a bad choice, but pipewire-gstreamer- git doesn't look good either. It sounds like gstreamer is specifically enabled (in contrast to the official package) for some reason.

It sounds *to me* like gstreamer is specifically enabled (in contrast to "pipewire-git") for some reason. i.e. the point of contrast is pipewire-git, not pipewire, due to pipewire-gstreamer-git minus the substring "-gstreamer" being the former, not the latter.

Fine, I now understand that "first come first use" always have higher priority. I am willing to accept this, but is it written somewhere? If not, I hope you can make it clear in the future.

Given a dispute where both sides have subjective arguments, which other tiebreaker do you propose?

I admit it isn't obvious from just the package name, but I am curious, what kind of privileged information do you need to acquire when you can just look at the PKGBUILD to find the difference?

The privileged information is someone telling me directly, and the whole point of my statement was that I'm claiming you can't "just look" because it's too easy to *over*look.

...

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

That was never the intention. I am simply not satisfied with any possible workarounds we have for now, that's why I am trying to discuss for a better solution. If that looks bad to you then I feel sorry.

...

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

Well, now you would like to assume that I intend to be malicious and you are prepared to apply restrictive measure, just because I have some opinions you don't agree with in some email exchanges? Or is my uploading of pipewire-nightly such an unforgivable violation of some rule that must be corrected with an account ban?

To save both of us some trouble I will now step out of this as you wish.

Hmm, well, it looked to me like post hoc rationalization of your original upload with a refusal to acknowledge it as problematic. Uploading the package may have been wrong, but mistakes can be pardoned as long as they're not repeated. I don't plan on banning you at all! I'm merely decidedly unsure, from your replies, whether you acknowledge it as, indeed, being a problem. Therefore I was concerned that in the future, if you ever get into a debate with a maintainer over another package about the right options to use, you might do the same "use a different VCS/devel suffix to re-upload the package in order to circumvent the upload restrictions, without properly namespacing it using a distinctive keyword" thing. -- Eli Schwartz Bug Wrangler and Trusted User