On Sat, Feb 22, 2020 at 09:59:00AM -0500, Santiago Torres-Arias via arch-dev-public wrote:
To make a long story short, I consider broken geolocation sufficient reason for removal. I don't mind it being broken for my own use, but shipping a package with broken functionality due to lack of upstream support does not sit well with me.
The short story doesn't accurately reflect reality. There's still upstream support, you've just not been willing to conform to the new officially supported process.
To protect against systems with outdated Chromium (following the stable release of version 82), at the beginning of April I intend to post a news item about the need to switch to another browser. That is assuming no solution is found and nobody objects to the removal or wishes to continue maintenance of the package with reduced functionality.
If anyone wants help in getting Geolocation working again, please let me know.
I'm curious, do you have a reference on how the process has changed? I think it'd be easier for people to gauge interest if they know what the new process entails. I'm also wondering if the billing requirement could be handled by SPI or some other organization-level approach....
The old process was essentially "know someone on the inside". Billing and access for Maps-based APIs has a loooooooong history. It existed before Google was really in the business of selling other APIs. Thus, it's gone through multiple iterations and a somewhat independent evolution. Lately, that's changed and it's now using standard internal infrastructure. As a side effect, the backdoor that Chrome developers used to be able to provide to distros is no longer available The new process is well-described here: https://support.google.com/nonprofits/answer/3367237?hl=en dR