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