[aur-requests] [PRQ#22879] Deletion Request for pipewire-nightly

[Eli Schwartz]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-requests/attachments/20201231/328771fd/attachment.sig>