[PRQ#59191] Deletion Request for widevine
MarsSeed [1] filed a deletion request for widevine [2]: This package is broken and not compatible with Arch Linux x86_64. It is also unneeded for Chromium or Firefox, as both of them can download the widewine module on-demand, if the user enables support for DRM-protected content. There is an AUR/chromium-widevine [a] that is compatible with Arch Linux and can be used with other packages that need widewine, like the silo-{netflix,primevideo} standalone apps or the qtwebflix-git plugin. Therefore keeping AUR/widewine is both pointless and superfluous. [a]: https://aur.archlinux.org/packages/chromium-widevine [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/widevine/
On 15/04/2024 15:48, notify@aur.archlinux.org wrote:
MarsSeed filed a deletion request for widevine:
This package is broken and not compatible with Arch Linux x86_64.
If this is true, then please leave a comment so I can fix it. It's supposed to work for archlinux x86_64. It was still working for me a few weeks ago.
It is also unneeded for Chromium or Firefox, as both of them can download the widewine module on-demand, if the user enables support for DRM-protected content.
Sorry, but the same is true for chromium-widevine.
There is an AUR/chromium-widevine [a] that is compatible with Arch Linux and can be used with other packages that need widewine, like the silo-{netflix,primevideo} standalone apps or the qtwebflix-git plugin.
Therefore keeping AUR/widewine is both pointless and superfluous.
Let's not beat around the bush and address the elephant in the room: this package got flagged because it's mainly useful for architectures other than x86_64 (i.e. ARM). If so, please be open about this and mention this as the main reason. BTW, this package does the same and *more* than chromium-widevine and adds *unique* features for firefox (even for x86_64) and for other platforms. I'm all in favour of merging it with chromium-widevine if that package takes over these unique features. I'm not going to argue against the current AUR terms-of-service, but, taking a step back: in view of the running RFC [1] wouldn't it be a good idea to at least temporarily pause the hunt for ARM-focused AUR packages until that RFC has run its course? KR Bart [1] https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/32
Request #59191 has been Rejected by Muflone [1]: see previous package maintainer answer [1] https://aur.archlinux.org/account/Muflone/
On 28 April 2024 17:29:00 GMT+02:00, notify@aur.archlinux.org wrote:
Request #59191 has been Rejected by Muflone [1]:
see previous package maintainer answer
[1] https://aur.archlinux.org/account/Muflone/ @Muflone, what do you mean exactly?
The package is not buildable and installable on Arch Linux due to missing a dependency, 'glibc-widevine'. That was an ARM-only older, patched variant of glibc. Also it is not true that this package offers anything useful on Arch Linux. Repo's Chromium and Firefox already has widevine support, and AUR/chromium-widevine offers this runtime for other executables.
Request #59191 has been Rejected by Muflone [1]:
see previous package maintainer answer
[1] https://aur.archlinux.org/account/Muflone/ @Muflone, what do you mean exactly?
The package is not buildable and installable on Arch Linux due to missing a dependency, 'glibc-widevine'. That was an ARM-only older, patched variant of glibc.
Also it is not true that this package offers anything useful on Arch Linux. Repo's Chromium and Firefox already has widevine support, and AUR/chromium-widevine offers this runtime for other executables.
The package widevine builds in chroot and installs fine in Arch Linux. The glibc-widevine dependency is for ARM builds only. Best regards -- Fabio Castelli aka Muflone
On 28 April 2024 18:48:44 GMT+02:00, Muflone <muflone@archlinux.org> wrote:
Request #59191 has been Rejected by Muflone [1]:
see previous package maintainer answer
[1] https://aur.archlinux.org/account/Muflone/ @Muflone, what do you mean exactly?
The package is not buildable and installable on Arch Linux due to missing a dependency, 'glibc-widevine'. That was an ARM-only older, patched variant of glibc.
Also it is not true that this package offers anything useful on Arch Linux. Repo's Chromium and Firefox already has widevine support, and AUR/chromium-widevine offers this runtime for other executables.
The package widevine builds in chroot and installs fine in Arch Linux.
The glibc-widevine dependency is for ARM builds only.
Best regards
And what is the rationale of keeping this duplicate of AUR/chromium-widevine?
Hello
Request #59191 has been Rejected by Muflone [1]:
see previous package maintainer answer
[1]https://aur.archlinux.org/account/Muflone/ @Muflone, what do you mean exactly?
The package is not buildable and installable on Arch Linux due to missing a dependency, 'glibc-widevine'. That was an ARM-only older, patched variant of glibc.
Also it is not true that this package offers anything useful on Arch Linux. Repo's Chromium and Firefox already has widevine support, and AUR/chromium-widevine offers this runtime for other executables.
The package widevine builds in chroot and installs fine in Arch Linux.
The glibc-widevine dependency is for ARM builds only.
Best regards
And what is the rationale of keeping this duplicate of AUR/chromium-widevine?
@Bart De Vries would be kind to explain how the widevine package does "*more* than chromium-widevine" and "adds *unique* features for firefox" as your previous reply? Is there some reason to keep this package? How this differs from chromium-widevine ? Best regards -- Fabio Castelli aka Muflone
Hi, The chromium-widevine package only covers chromium and chromium-derivatives (and only x86_64), as evidenced by it being installed into `/usr/lib/chromium` where (only) chromium will find it automatically. As the pinned comment for chromium-widevine already mentions, this is not strictly needed anymore, since most browsers these days are able to download the widevine libs automatically from google on first use, and install them into the user profile directory in `/home/user`. The unique thing about this package is that it can install the widevine binaries in a central location in `/opt`, and will register the libs with chromium and firefox to use them from that central location with no user setup required. This avoids having multiple copies for each browser and user. NB: This can be expanded to other browsers as well. I've been meaning to add automatic Vivaldi registering but have not found the time yet. Browsers like Angelfish and Falkon and apps like kodi can also be made to recognize the central lib with a few manual steps. Note that, similar to e.g. spotify, this package can never be incorporated into a main package repository since it's pulling in closed-source copyrighted libs that don't allow redistributing but are allowed to be downloaded directly by the users. I know it's offtopic, but the other unique capability is that this adds additional support for ARM. Google don't serve linux ARM widevine binaries from their main website, so no browsers are able to retrieve the addon on first use. This package retrieves the publicly available binaries for/from chromeos which also work with plain linux on ARM. PS: The OP mentioned that this package is not needed because firefox will automatically download the libs on first use. This is true, but - as mentioned above - the same holds for chromium, so following that reasoning, all widevine related packages should be removed from AUR. PS2: The version numbering comment is a valid point: the version number of the most recent widevine lib differs between platforms (ask google why). I should change the package to use the most recent x86_64 version number as the main one. (Similar to git packages, the current PKGBUILD will update to the correct version number on build. So the actually installed package will have the correct version number for the respective platform.) Best regards, Bart On 30/04/2024 01:55, Muflone wrote:
Hello
Request #59191 has been Rejected by Muflone [1]:
see previous package maintainer answer
[1]https://aur.archlinux.org/account/Muflone/ @Muflone, what do you mean exactly?
The package is not buildable and installable on Arch Linux due to missing a dependency, 'glibc-widevine'. That was an ARM-only older, patched variant of glibc.
Also it is not true that this package offers anything useful on Arch Linux. Repo's Chromium and Firefox already has widevine support, and AUR/chromium-widevine offers this runtime for other executables. The package widevine builds in chroot and installs fine in Arch Linux.
The glibc-widevine dependency is for ARM builds only.
Best regards
And what is the rationale of keeping this duplicate of AUR/chromium-widevine?
@Bart De Vries
would be kind to explain how the widevine package does "*more* than chromium-widevine" and "adds *unique* features for firefox" as your previous reply?
Is there some reason to keep this package? How this differs from chromium-widevine ?
Best regards
-- Fabio Castelli aka Muflone
Hello Il 06/05/24 11:20, Bart De Vries ha scritto:
Hi,
The chromium-widevine package only covers chromium and chromium-derivatives (and only x86_64), as evidenced by it being installed into `/usr/lib/chromium` where (only) chromium will find it automatically.
As the pinned comment for chromium-widevine already mentions, this is not strictly needed anymore, since most browsers these days are able to download the widevine libs automatically from google on first use, and install them into the user profile directory in `/home/user`.
The unique thing about this package is that it can install the widevine binaries in a central location in `/opt`, and will register the libs with chromium and firefox to use them from that central location with no user setup required. This avoids having multiple copies for each browser and user.
Therefore, apart the browsers registration, this package offers the same content of chromium-widevine, I suppose. Its plus is registering the same plugin in multiple browsers location. So in the end, why don't you simply use the chromium-widevine dependency to download the library and create the needed configuration for the others browsers? This wouldn't result in a duplicate package, a more simpler maintenance and also better a more specific task for the package. All the rest seems not an interesting argument against the package deletion. Regards -- Fabio Castelli aka Muflone
On 12/05/2024 14:06, Muflone wrote:
Therefore, apart the browsers registration, this package offers the same content of chromium-widevine, I suppose.
Its plus is registering the same plugin in multiple browsers location.
So in the end, why don't you simply use the chromium-widevine dependency to download the library and create the needed configuration for the others browsers?
This wouldn't result in a duplicate package, a more simpler maintenance and also better a more specific task for the package.
All the rest seems not an interesting argument against the package deletion. Sorry about the late reply.
To be honest, my preference would still be to merge both packages under the "widevine" name. I'm willing to maintain such a merged package. Supporting evidence: - This package handles more browsers and more architectures than chromium-widevine. - There is a pinned remark on the chromium-widevine AUR page saying: "I'll maintain this package for a while for the other systems that use it." - chromium-widevine downloads the entire chrome browser to only extract the lib. The widevine package downloads the separately packaged lib directly from google. This is much more efficient. But, if you think this is not the way forward, that's also fine. Then please tell me what you would prefer me to do to avoid this package getting deleted. If you want me to do instead:
So in the end, why don't you simply use the chromium-widevine dependency to download the library and create the needed configuration for the others browsers?
then that's also fine by me. Best regards, Bart
Hi Bart
To be honest, my preference would still be to merge both packages under the "widevine" name. I'm willing to maintain such a merged package.
It won't happen as chromium-widevine is way more more popular, still maintained, has a huge number of votes and comments, while widevine is a mere duplicated package with a very strict use case, mainly to support different architectures not supported by Arch Linux with only 1 vote and only 6 months old.
Supporting evidence: - chromium-widevine downloads the entire chrome browser to only extract the lib. The widevine package downloads the separately packaged lib directly from google. This is much more efficient.
The straightforward solution would be to use the widevine source in the chromium-widevine package, but I doubt the maintainer is willing to do that. In the case the chromium-widevine package would be abandoned, you could maintain it, but until that moment arrives, I think there's no point in keeping the duplicated package, only for supporting the unsupported architectures or to add thirdy part browsers. Unfortunately after one month of discussion I still cannot find any reasons to keep this package. The package will be removed in the next days. Regards -- Fabio Castelli aka Muflone
Hi Fabio,
To be honest, my preference would still be to merge both packages under the "widevine" name. I'm willing to maintain such a merged package.
It won't happen as chromium-widevine is way more more popular, still maintained, has a huge number of votes and comments, while widevine is a mere duplicated package with a very strict use case, mainly to support different architectures not supported by Arch Linux with only 1 vote and only 6 months old.
Well, maybe that's because there were previous packages with the same functionality that have been deleted from AUR before this one, which had more votes. (Those were ARM-centered, so I'm not going to argue about that here.) However, when those got deleted I asked the AUR trusted user what I would need to do to comply with the guidelines. I got the feedback that as long as the package would work for x86_64 and is well-maintained, it should be fine. So I spent the effort to make a universal package, only for it to get deleted again. This is so incredibly frustrating... Sorry to use a whataboutism, but if this is really the reason, then why is the vivaldi-widevine package allowed to exist? That is an *exact* duplicate of chromium-widevine, and has been on AUR for 5 years without getting deleted. Same for qt5-webengine-widevine and qt6-webengine-widevine.
Supporting evidence: - chromium-widevine downloads the entire chrome browser to only extract the lib. The widevine package downloads the separately packaged lib directly from google. This is much more efficient.
The straightforward solution would be to use the widevine source in the chromium-widevine package, but I doubt the maintainer is willing to do that.
In the case the chromium-widevine package would be abandoned, you could maintain it, but until that moment arrives, I think there's no point in keeping the duplicated package, only for supporting the unsupported architectures or to add thirdy part browsers.
See vivaldi-widevine, qt5-webengine-widevine and qt6-webengine-widevine mentioned above. Those packages add a whole lot less extras than this package (on x86_64), but somehow they can continue to exist because they probably weren't attracting any attention raised by ARM folks.
Unfortunately after one month of discussion I still cannot find any reasons to keep this package.
Those were two emails. Sorry that I forgot to reply in time. PS: Since this seems to be the end of the line: I really didn't want to bring this up, but I'm really sick and tired of the witch-hunt for ARM-related packages. In my experience it's always the same user (I'm not going to mention the name) that's actively hunting for ARM-related packages to submit deletion requests for. That same person keeps on mentioning that the packages should move to some non-existent ALARM AUR infrastructure. Please also note that ArchlinuxARM is using "Archlinux" as part of its name under license from the ArchLinux project. I've brought this up several times now with Archlinux maintainers: please make up your mind: either you consider ArchlinuxARM to be a sister project and allow it *some* leeway, or you withdraw the license to use the name to make clear that it's completely unrelated. Sorry, I needed to get that out of my system apparently... :-) I'm just getting so damn frustrated by having packages deleted that I'm maintaining with heart and soul, and have poured hours of research into, just because they attract extra attention caused by people using ARM architectures. Cheers, Bart
Hello again
To be honest, my preference would still be to merge both packages under the "widevine" name. I'm willing to maintain such a merged package.
It won't happen as chromium-widevine is way more more popular, still maintained, has a huge number of votes and comments, while widevine is a mere duplicated package with a very strict use case, mainly to support different architectures not supported by Arch Linux with only 1 vote and only 6 months old.
Well, maybe that's because there were previous packages with the same functionality that have been deleted from AUR before this one, which had more votes. (Those were ARM-centered, so I'm not going to argue about that here.) However, when those got deleted I asked the AUR trusted user what I would need to do to comply with the guidelines. I got the feedback that as long as the package would work for x86_64 and is well-maintained, it should be fine. So I spent the effort to make a universal package, only for it to get deleted again. This is so incredibly frustrating...
I told you before, the optimal solution would be to use the same source and having no duplicated packages. Side-node: pulling a dependency and adding a symlink shouldn't be a reason to have a new package but it could be somehow "tolerated" or "opinionated" or requiring a discussion somehow.
Sorry to use a whataboutism, but if this is really the reason, then why is the vivaldi-widevine package allowed to exist? That is an *exact* duplicate of chromium-widevine, and has been on AUR for 5 years without getting deleted. Same for qt5-webengine-widevine and qt6-webengine-widevine.
Are you aware I left a lot of time to discuss about this package? I don't know the details about every package so I ask the maintainers their opinion. Unfortunately if the maintainer cannot give valid reason to having created a duplicate, there's no point in having a duplicate. Probably, having the same exact discussion about vivaldi-widevine package, would result in having the same result.
Unfortunately after one month of discussion I still cannot find any reasons to keep this package.
Those were two emails. Sorry that I forgot to reply in time.
PS: Since this seems to be the end of the line: I really didn't want to bring this up, but I'm really sick and tired of the witch-hunt for ARM-related packages.
This is entirely your fantasy: I asked you the reasons for having this duplicated package, I was not interested in any ARM argument. Plus the first widevine deletion request was rejected by myself believing it was a different package, then this discussion was raised. Packages compatible with Arch Linux x86_64 architecture (the only Arch Linux supported architecture) are welcome, as long they have valid reasons to exist, i.e. not duplicated or broken packages. ARM is 100% unrelated to this topic, unfortunately it seems the only valid reason for you to have this duplicated package is to justify an ARM support. I'll repeat for my last time, this package will be deleted for being a duplicated. It was discussed with the maintainer and he agreed both packages offers the same software, they are only differently packaged.
Please also note that ArchlinuxARM is using "Archlinux" as part of its name under license from the ArchLinux project. I've brought this up several times now with Archlinux maintainers: please make up your mind: either you consider ArchlinuxARM to be a sister project and allow it *some* leeway, or you withdraw the license to use the name to make clear that it's completely unrelated.
Arch Linux ARM is a port of Arch Linux for ARM architecture, it's not a project affiliated to Arch Linux, it's not run under the same servers, not by the same people. Don't ask the Arch Linux team to support a different distribution, please. The architecture is already admitted in the PKGBUILDs. Sorry for your frustration but it seems your issue is with ARM packages, wanting to support them at any cost in the AUR, at the point to create duplicated packages. Instead collaborate with the existing packages' maintainers and eventually add extra architectures, if the software supports them. This ARM discussion is entirely out of this package topic. Regards -- Fabio Castelli aka Muflone
participants (4)
-
Bart De Vries
-
Marcell Meszaros
-
Muflone
-
notify＠aur.archlinux.org