And here you are: https://together.jolla.com/question/12655/packaging-and-distributing-data-files-or-plugins/
On Thu, Jan 9, 2014 at 1:50 PM, Thomas Perl <th.p...@gmail.com> wrote: > Hi, > > On 09 Jan 2014, at 09:05, Wim de Vries <wsvr...@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 -- Luciano Montanaro Anyone who is capable of getting themselves made President should on no account be allowed to do the job. -- Douglas Adams _______________________________________________ SailfishOS.org Devel mailing list
