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
