The rest of the fdroidserver code uses 'appid' or 'packageName'. The official
Android name is "Application ID". "Package Name" is the Java term, and it
is used in Android in Java code.
https://gitlab.com/eighthave/fdroiddata/-/jobs/611438997
Otherwise it fails to install:
```
gpg : Depends: gpgconf (= 2.2.20-1~bpo9+1)
Depends: libassuan0 (>= 2.5.0) but 2.4.3-2 is to be installed
Depends: libgpg-error0 (>= 1.35) but 1.26-2 is to be installed
```
* 7e8c244473
* !769
This makes update.py:main a lot saner by removing a lot of the
implicit assumptions between the different stages of generating the
repository index.
* mostly unify repo and archive processing, that means the archive is
now actually getting the same treatment regarding i.e. fastlane data.
Previously the archive didn't get considered at all here.
* already filter the list of apps to include in a repo in update.py and
give that prefiltered list to index. This makes sure we actually only
copy fastlane/triple-t/etc. stuff for apps ending up in the index.
This both, can save a lot of time if there are a lot of old /build
dirs lying around and doesn't clutter /repo with things that aren't
referenced from the index.
Closesfdroid/fdroidserver#524
This is a historic detail of the index format, so move it there.
For wiki update and status json there's really no reason why this should
be done in alphabetic app name order. Use the default sort order by
appid.
Previously this was magically capturing the apps dict when passing it around as a
function. This also moved the code to the metadata module.
Add a test doing read_metadata where the linkresolver is used. This
happens when the apps we read have a [[app.id]] link to another app.
Liberapay was originally included using a numeric ID, since they had
not yet finalized the public URLs. Now it is a username. So this
logic prefers the username in Liberapay: field, and keeps the old
LiberapayID: to ease migration. LiberapayID: will not override
Liberapay:. Clients are expected to prefer Liberapay: over LiberapayID:
GitHub has specified FUNDING.yml, a file to include in a git repo for
pointing people to donation links. Since F-Droid also points people
to donation links, this parses them to fill out Donate:
and OpenCollective:. Specifying those in the metadata file takes
precedence over the FUNDING.yml. This follows the same pattern as how
`fdroid update` includes Fastlane/Triple-T metadata. This lets the
git repo maintain those specific donations links themselves.
https://help.github.com/en/articles/displaying-a-sponsor-button-in-your-repository#about-funding-files
The test file was generated using:
```python
import os, re, yaml
found = dict()
for root, dirs, files in os.walk('.'):
for f in files:
if f == 'FUNDING.yml':
with open(os.path.join(root, f)) as fp:
data = yaml.safe_load(fp)
for k, v in data.items():
if k not in found:
found[k] = set()
if not v:
continue
if isinstance(v, list):
for i in v:
found[k].add(i)
else:
found[k].add(v)
with open('gather-funding-names.yaml', 'w') as fp:
output = dict()
for k, v in found.items():
output[k] = sorted(v)
yaml.dump(output, fp, default_flow_style=False)
```
This sdk is open source. It was added because appcenter has a dependency
to play-services. It's possible though to build an app using appcenter
that doesn't pull in play services, so we can't blanket ban the sdk.
The appcenter-push modules has obvious refenrences to firebase, so it's
safe to error on that.
Ref: https://phabricator.wikimedia.org/T254980
