On 29 April 2024 20:16:54 GMT+02:00, Dan Johansen <danjohan...@strits.dk> wrote: > >Den 29.04.2024 kl. 20.09 skrev not...@aur.archlinux.org: >> MarsSeed [1] filed a deletion request for widevine [2]: >> >> Re-filing a deletion request due to not receiving any response [a] as >> to the rationale to keep this duplicate of the properly packaged >> AUR/chromium-widevine. [b] >> >> The AUR/widevine package was created with the sole purpose of offering >> ARM support, and x86_64 was only added to mask its intent. >> >> Also I believe it is not okay to create duplicates on AUR when there >> is already a maintained package which works with Arch Linux. >> AUR/widevine's maintainer should collaborate with that of >> AUR/chromium-widevine and suggest enhancements there, if there are >> relevant ones. >> >> In addition, AUR/widevine has other problems. As its used release >> deliverables for different platforms diverge in their version: >> >> - AUR/widevine pkgver: 4.10.2252.0 >> - x86_64: upstream - 4.10.2710.0 (released 2024-02-12) >> - aarch64/armhf: RaspberryPi.org/Debian - 4.10.2252.0 (released >> 2023-10-05) >> - (AUR/chromium-widevine pkgver: 4.10.2710.0, released 2024-02-12) >> >> As the RPI distro does not carry the latest version, it seems not to >> be viable to carry binaries for different architectures in the same >> PKGBUILD. >> >> Which leads me to conclude that a PKGBUILD for the RPI releases should >> be submitted to the ArchLinuxARM.org repositories only. >The problem with that is that widevine is not open source and not >distributable, so the package is not allowed to be in any repository, thus an >AUR package is required. >> >> That would actually benefit users more, while not cluttering the AUR. >> >> [a]: >> https://lists.archlinux.org/archives/list/aur-requests@lists.archlinux.org/thread/IAHLWRGRNHHUZRU2LRMX5UTZUNGJBAUO/#5CT5XAQZNIHQYPSRZ6CMDTY67XE3QOU2 >> [b]: >> https://aur.archlinux.org/packages/chromium-widevine >> >> [1] https://aur.archlinux.org/account/MarsSeed/ >> [2] https://aur.archlinux.org/pkgbase/widevine/
Hm, in that case, I believe the best course of action would be yet to add the RaspberryPi release tarballs to AUR/chromium-widevine, and its pkgver could reflect the divergent versions in the following way (example): pkgver=4.10.2710.0_rpi4.10.2252.0 Can you maybe request collaboration with AUR/chromium-widevine's maintainer to make the necessary changes in that PKGBUILD? That would be the best in my opinion. Thank you for considering my proposal.
