This seems like a bug of some sort in fdroidserver; there's no apparent
reason why these names should contain HTML escape sequences. The name
fields are plaintext strings, so it's not like they can contain any HTML
elements.
One possible explanation is how fdroidserver obtains these strings from
the built APKs. Since the information is inside xml files, perhaps the
code is buggy and doesn't unescape the strings before using them for the
index.
For now, do the unescaping on the client side.
This way, users can simply do:
go get mvdan.cc/fdroidcl
Instead of the repetitive:
go get mvdan.cc/fdroidcl/cmd/fdroidcl
The cmd/... pattern only makes sense if the repository has many
commands, or if the name of the repository and command don't match.
Neither is the case here.
That is, downloading /index-v1.jar instead of /index.jar.
This lets us clean up some code, as the old format was a bit more
complex and made use of some slightly weird encodings. But most
importantly, the new index format includes some extra information that
we might start using soon.
I have been moving all github.com/mvdan/... packages to mvdan.cc/...
recently - do this one too.
basedir was only really used by these packages, so merge it in to
simplify building and packaging the tool.
The new cache format didn't encode the repos properly, which lead to
crashes. Since we're modifying the cache format, introduce a version and
discard all previous caches (defaulting to version 0).
Fixes#19.
Otherwise, treat all apks as compatible. Remove all the VName matching
code as discussed on github, to stay close to what the Android client
does. We should not be using version names for anything relevant anyway.
It does not really matter that much which APK we take app icon from.
They rarely change and it's a question of aestetics.
Just take the latest icon version, like we do with app description.
Suggested APK must be compatible with a particular device. This is
always one of the set of suggested APKs. This set contains APKs with the
same version string but different version codes (flavours of the same
version, e.g. targeting different hardware architectures).