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

Eli Schwartz eschwartz at archlinux.org
Thu Dec 31 12:22:49 UTC 2020


On 12/31/20 4:56 AM, Haochen Tong wrote:
> On Wed, 2020-12-30 at 20:41 +0000, notify at 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

-------------- 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/4f294323/attachment.sig>


More information about the aur-requests mailing list