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

Thu Jan 9 22:56:37 UTC 2014

9.1.2014 23:27, 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!
Well, a TOH with barometer & a variometer application might be a nice 
combo for glider pilots. :)

>
> 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
>>
>
> _______________________________________________
> SailfishOS.org Devel mailing list