make it really easy to upgrade unsigned repos to signed
As a key step to removing support for unsigned repos from fdroidclient (https://gitlab.com/fdroid/fdroidclient/issues/12), this merge request makes `fdroid update` require a signing key. If there is no keystore, it'll prompt the user to create one using `fdroid update --create-key`.
This closes#13
See merge request !48
This moves the method for generating a new keystore for the repo signing
key to a common function so that it can be used in more subcommands beyond
`fdroid init`. The immediate idea is to make `fdroid update --create-key`
upgrade unsigned repos to signed ones so we can make fdroidclient only use
signed repos.
This makes `fdroid init` create a complete, self-contained repo in a single
folder. That makes it easily transferable, backupable, etc. It also means
that `fdroid update` can add a keystore to an existing unsigned repo
without having to worry about finding the right folder or overwriting any
other existing files.
Fix project.properties dependency issue
Correctly place scrlib references also
in the case there is no project.properties file
present in the original repository.
This commit fixes a problem, which was introduced with
021df3c424: If no
project.properties file exists in the original
project's source repo, place_srclib will not place
a dependency --- even if there should be one:
> if not os.path.isfile(proppath):
> return
Example app: fdroiddata/metadata/org.berlin_vegan.bvapp.txt
See merge request !47
Correctly place scrlib references also
in the case there is no project.properties file
present in the original repository.
This commit fixes a problem, which was introduced with
021df3c424: If no
project.properties file exists in the original
project's source repo, place_srclib will not place
a dependency --- even if there should be one:
> if not os.path.isfile(proppath):
> return
Example app: fdroiddata/metadata/org.berlin_vegan.bvapp.txt
If the comparison between the provided APK and the built APK is verified,
then there is no need to keep the old comparison files around. On big build
servers like f-droid.org, there will be thousands of leftover dirs from all
the builds, so this is necessary.
By not setting sdk_path when /usr/bin/aapt is found, sdk_path then defaults
to $ANDROID_HOME when its used. Since in this case, aapt will be used from
the system path, using aapt entirely ignores sdk_path. If the user runs
`fdroid build` in this setup, sdk_path will be $ANDROID_HOME, so it should
check the env vars for it, but maybe that doesn't actually work like that
yet.
This is a more flexible approach than testing for the complete SDK and
build-tools up front. This will only test for the commands that are
actually being run, so that if you only have `aapt` installed, you can do
`fdroid update` without errors, but other commands will still give
appropriate errors.
This also makes the build_tools item in config.py optional, it is only
needed if you want to force a specific version of the build-tools.
I wrote up the feature to automatically generate symlinks with a constant name
that points to the current release version. I have it on by default, with a
*config.py* option to turn it off. There is also an option to set where the
symlink name comes from which defaults to app['Name'] i.e. F-Droid.apk, but
can easily be set to app['id'], i.e. _org.fdroid.fdroid.apk_. I think the best
place for the symlinks is in the root of the repo, so like
https://f-droid.org/F-Droid.apk or https://guardianproject.info/fdroid/ChatSecure.apk
For the case of the current FDroid static link https://f-droid.org/FDroid.apk
it can just be a symlink to the generated one (https://f-droid.org/F-Droid.apk
or https://f-droid.org/org.fdroid.fdroid.apk). Right now, this feature is all
or nothing, meaning it generates symlinks for all apps in the repo, or none. I
can’t think of any problems that this might cause since its only symlinks, so
the amount of disk space is tiny. Also, I think it would be useful for having
an easy “Download this app” button on each app’s page on the “Browse” view. As
long as this button is less prominent than the “Download F-Droid” button, and
it is clear that it is better to use the FDroid app than doing direct
downloads. For the f-droid.org repo, the symlinks should probably be based on
app['id'] to prevent name conflicts.
more info here:
https://f-droid.org/forums/topic/static-urls-to-current-version-of-each-app/
Done after verifying that they match ones built using a recipe.
Everything in the metadata should be the same as normal, with the
addition of the Binaries: directive to specify where (with pattern
substitution) to get the binaries from.
Publishing only takes place if there is a proper match. (Which seems
very unlikely to be the case unless the exact same toolchain is used, so
I would imagine that unless the person building and signing the incoming
binaries uses fdroidserver to build them, probably the exact same
buildserver id, they will not match. But at least we have the
functionality to support that.)
* Default paths are not expanded
* When writing to config.py in "fdroid init", don't write expanded paths
either
* Support changes in e.g. $ANDROID_HOME after a config.py is generated thanks
to the fix above
Reasons:
* Cloning a svn repo via svn doesn't fetch the entire history
* Svn checkout is incredibly slow
* Svn doesn't have important features such as a 'clean' command
The only reason why we kept svn was for anonymous logins to repositories. This
is no longer a reason since git-svn also supports them.
This gives us flexibility in how the blocks of text can be formatted in
config.py, but also provides a more useful format for displaying since the
client can decide where to wrap the text.
