[SailfishDevel] How to install user (controlled) data files for my app avoiding /usr/share

[Wim de Vries]

Thanks Thomas for the explanation.
Indeed, I think I will stick to a minimal persistent data set  to enable 
the user to play with.
For the open/free data I will have a look at SF.
The maps created by the user (with an accompanying  desktop application) 
will have to be copied to sailfish via USB to a dir in $XDG_DATA_HOME.
The good thing is that I am not in a hurry, don't expect many pilots 
with a Jolla for now :-)
And, in the long term ... A pilot Other Half!

r
wim

On 01/09/2014 01:50 PM, Thomas Perl wrote:
> Hi,
>
> On 09 Jan 2014, at 09:05, Wim de Vries <wsvries at xs4all.nl> wrote:
>> I am converting my aircraft navigation app to Sailfish.
>> It comes (default) with OpenStreet based maps + 3D data files of Western Europe (in RPM).
>> Most users will use this map, but some users may use their home made maps (generated by a PC application).
>> In the latter case, the users will delete this W-Europe map (it takes up quite some disk space).
>> So far so good, but the installation/RPM is a problem:
>>
>> Harbour says that I should install the app data (very much bytes for the W-Eu map) in /usr/share/$NAME and in the first run of the app, copy them to $XDG_CONFIG_HOME/$NAME.
>> But  now I am stuck with an enormous amount of (useless) data in /usr/share/$NAME that cannot be removed.
>>
>> Any suggestions?
> The “copy stuff to the home directory of the user” is only relevant if you want to e.g. ship default config files and install them to the config directory on first start (the suggestion was put in place when somebody wanted to install files to /home/nemo/.config/ in the RPM file, something that will also lead to unhappy people in case of package upgrades, and that was suggested as best practice if the code can’t deal with missing config files - which it ideally should ;)). For big files, obviously it doesn’t make sense to copy them to $XDG_CONFIG_HOME/$NAME. Instead, what you could do is install them to /usr/share/$NAME, and then just have a flag in $XDG_CONFIG_HOME/$NAME if the user wants to disable the system-wide data (of course, this doesn’t free the data, but in case hiding/not loading the data will improve e.g. the startup time or user experience, it could still make sense).
>
> For data that the package manager installs, only the package manager should modify/remove the data. Making /usr/share/$NAME world-writable is not allowed per harbour rules, and for good reason - if the user would e.g. delete the pre-installed maps there, they would re-appear every time the app is upgraded, or if the user modifies the data there (or the app), these changes would be overwritten by a package upgrade.
>
> Also, another thing: Having big pre-installed data in the app packaged (=inside the RPM) is bad, as it will require this data to be re-downloaded every time the package is installed, and (during installation time) will take up the space for the - temporarily downloaded - RPM and the extracted data (you will need ~ 400 MB free to extract a 200 MB RPM file with 200 MB of data inside, not taking into account compression and stuff).
>
> So, you have an app plus some big data that probably doesn’t change as often as the code does (either it changes more often or it doesn’t change as often - the data doesn’t usually have anything to do with code updates to your app except if you happen to do some data format changes).
>
> There are basically two options:
>   1. Don’t ship any data with your application
>      - Small download and upgrade size, no wasted space
>      - For the “pre-packaged” maps, you could download them in the app on first start
>   2. Ship data with your application, and don’t let the user delete it
>      - No need to host any data packages
>      - Package upgrades and first download will be unnecessarily large
>
> I’d suggest you do variant 1: Users who have a good connection might not want/need to download much data upfront, they might just want to try out your app (=easier when it’s a smaller download) and only after they’ve tried and liked your app, they might go into the in-app menu and select something like “download pre-packaged maps”. As your data seems to be open in some sense, you might be able to either download it directly from the OSM servers, or you package it up and put it up on some hosting service (e.g. sourceforge.net works well for hosting such data downloads, including mirroring - but any other service or your own web server would work just as well).
>
> If you really do want to ship the data with your package, it should not be possible to delete it, only possibly hide it from the UI of the application via a setting that is stored in $XDG_CONFIG_HOME/$NAME. By the way, all the data that you download should go into $XDG_DATA_HOME, not $XDG_CONFIG_HOME (as the name suggests — this will allow backup and cleanup applications in the future to e.g. backup / clean only the data directory (keeping the config in place) or only deleting only the data). For data that you basically cache from a web services, such as map tiles, $XDG_CACHE_HOME/$NAME might be an even better place.
>
> Of course, you could also create a separate “Map pack” app entry for each pre-loaded packs that just contains the map data, although I’m not sure if we currently accept such “non-app” items (without a .desktop file and icon).
>
> For the future, if somebody wants to brainstorm it on together.jolla.com, we could have separate “data packages” for each app on harbour that the store client takes care of installing and updating independent of the app, which would also result in better bandwidth usage (data is only downloaded when updated, app package updates can be downloaded and installed independently). On Google Play, this mechanism is called “APK Expansion Files”: http://developer.android.com/google/play/expansion-files.html - something similar to that could solve the problem in your case, but we’re not there yet.
>
> HTH :)
> Thomas
>
> _______________________________________________
> SailfishOS.org Devel mailing list
>