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
