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

Wim de Vries wsvries at xs4all.nl
Fri Jan 10 06:56:24 UTC 2014


On 01/09/2014 11:56 PM, Martin Kolman wrote:
> 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. :)
Could be possible, but my current sensor is to big.

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



More information about the Devel mailing list