Discussion:
[SailfishDevel] How to install user (controlled) data files for my app avoiding /usr/share
(too old to reply)
Wim de Vries
2014-01-09 08:05:59 UTC
Permalink
Hi,
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?
Thanks.
Luciano Montanaro
2014-01-09 08:36:20 UTC
Permalink
Maybe make the application download the map on the first run?
But you must be able to provide the maps on a server in this case.

The additional benefit is that the user can skip downloading the data
if he knows it will not use it.

Luciano
Post by Wim de Vries
Hi,
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).
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?
Thanks.
_______________________________________________
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
Wim de Vries
2014-01-09 10:25:15 UTC
Permalink
Thanks.
Post by Luciano Montanaro
Maybe make the application download the map on the first run?
mm..
I cannot afford time/money for a server + support.
Only support for the app.
On the long term, users themselves may set up sth to share maps.
Post by Luciano Montanaro
But you must be able to provide the maps on a server in this case.
The additional benefit is that the user can skip downloading the data
if he knows it will not use it.
Never the case in first use. Only after some time of usage.
Post by Luciano Montanaro
Luciano
Post by Wim de Vries
Hi,
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).
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?
Thanks.
_______________________________________________
SailfishOS.org Devel mailing list
Reto Zingg
2014-01-09 16:02:51 UTC
Permalink
Hi,
Post by Wim de Vries
Thanks.
Post by Luciano Montanaro
Maybe make the application download the map on the first run?
mm..
I cannot afford time/money for a server + support.
if the data is 'free' (in the sense you don't want to specially protect
them) you could place it on e.g. http://sourceforge.net/ for download?
Or do they have now a days some limits (size, per/day/month) or so?

Or some git hoster, like github, gitorious, code.google.com etc... guess
also needs some check that it's not abusive...

br
Reto
Post by Wim de Vries
Only support for the app.
On the long term, users themselves may set up sth to share maps.
Post by Luciano Montanaro
But you must be able to provide the maps on a server in this case.
The additional benefit is that the user can skip downloading the data
if he knows it will not use it.
Never the case in first use. Only after some time of usage.
Post by Luciano Montanaro
Luciano
Post by Wim de Vries
Hi,
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).
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?
Thanks.
_______________________________________________
SailfishOS.org Devel mailing list
_______________________________________________
SailfishOS.org Devel mailing list
Wim de Vries
2014-01-09 22:01:59 UTC
Permalink
Thanks.
Post by Reto Zingg
Hi,
Post by Wim de Vries
Thanks.
Post by Luciano Montanaro
Maybe make the application download the map on the first run?
mm..
I cannot afford time/money for a server + support.
if the data is 'free' (in the sense you don't want to specially
protect them) you could place it on e.g. http://sourceforge.net/ for
download? Or do they have now a days some limits (size, per/day/month)
or so?
I will have try/check at SF. The orginal linux version -bit outdated but
stable- lives there as well ('openflightnav').
I did not put the free map data (450 MB) up there though. Will have a look.
Post by Reto Zingg
Or some git hoster, like github, gitorious, code.google.com etc...
guess also needs some check that it's not abusive...
br
Reto
Post by Wim de Vries
Only support for the app.
On the long term, users themselves may set up sth to share maps.
Post by Luciano Montanaro
But you must be able to provide the maps on a server in this case.
The additional benefit is that the user can skip downloading the data
if he knows it will not use it.
Never the case in first use. Only after some time of usage.
Post by Luciano Montanaro
Luciano
Post by Wim de Vries
Hi,
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).
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?
Thanks.
_______________________________________________
SailfishOS.org Devel mailing list
_______________________________________________
SailfishOS.org Devel mailing list
_______________________________________________
SailfishOS.org Devel mailing list
Jonni Rainisto
2014-01-09 08:40:09 UTC
Permalink
IMHO (Only my personal view, not official answer).

I would not copy readonly data to $XDG_CONFIG_HOME/$NAME, I would only copy the readwrite parts off from usr/share/appname.
And I would define the map data chmod 666 in spec so I could programitically remove the data.

________________________________________
From: devel-bounces at lists.sailfishos.org [devel-bounces at lists.sailfishos.org] on behalf of Wim de Vries [wsvries at xs4all.nl]
Sent: Thursday, January 09, 2014 10:05 AM
To: devel at lists.sailfishos.org
Subject: [SailfishDevel] How to install user (controlled) data files for my app avoiding /usr/share

Hi,
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?
Thanks.
_______________________________________________
SailfishOS.org Devel mailing list
Wim de Vries
2014-01-09 11:18:36 UTC
Permalink
Thanks.
Post by Jonni Rainisto
IMHO (Only my personal view, not official answer).
I would not copy readonly data to $XDG_CONFIG_HOME/$NAME, I would only copy the readwrite parts off from usr/share/appname.
And I would define the map data chmod 666 in spec so I could programitically remove the data.
I like your idea.
Hardly any experience with RPM though. I'll have to dive into that.

Sailfish people: please confirm if this is an allowed option.
Thanks.

R
wim
Post by Jonni Rainisto
________________________________________
From: devel-bounces at lists.sailfishos.org [devel-bounces at lists.sailfishos.org] on behalf of Wim de Vries [wsvries at xs4all.nl]
Sent: Thursday, January 09, 2014 10:05 AM
To: devel at lists.sailfishos.org
Subject: [SailfishDevel] How to install user (controlled) data files for my app avoiding /usr/share
Hi,
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).
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?
Thanks.
_______________________________________________
SailfishOS.org Devel mailing list
_______________________________________________
SailfishOS.org Devel mailing list
Ruslan Nigmatullin
2014-01-09 11:24:36 UTC
Permalink
I fear that removing installed files is bad idea as package manager can become crazy.
Post by Wim de Vries
Thanks.
?IMHO (Only my personal view, not official answer).
?I would not copy readonly data to $XDG_CONFIG_HOME/$NAME, I would only copy the readwrite parts off from usr/share/appname.
?And I would define the map data chmod 666 in spec so I could programitically remove the data.
I like your idea.
Hardly any experience with RPM though. I'll have to dive into that.
Sailfish people: please confirm if this is an allowed option.
Thanks.
R
wim
?________________________________________
?From: devel-bounces at lists.sailfishos.org [devel-bounces at lists.sailfishos.org] on behalf of Wim de Vries [wsvries at xs4all.nl]
?Sent: Thursday, January 09, 2014 10:05 AM
?To: devel at lists.sailfishos.org
?Subject: [SailfishDevel] How to install user (controlled) data files for my ????app avoiding /usr/share
?Hi,
?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).
?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?
?Thanks.
?_______________________________________________
?SailfishOS.org Devel mailing list
?_______________________________________________
?SailfishOS.org Devel mailing list
_______________________________________________
SailfishOS.org Devel mailing list
--
Ruslan Nigmatullin
Andrey Kozhevnikov
2014-01-09 11:26:50 UTC
Permalink
It shouldn't. It will just ignore not existing files.
Post by Ruslan Nigmatullin
I fear that removing installed files is bad idea as package manager can become crazy.
Post by Wim de Vries
Thanks.
Post by Jonni Rainisto
IMHO (Only my personal view, not official answer).
I would not copy readonly data to $XDG_CONFIG_HOME/$NAME, I would only copy the readwrite parts off from usr/share/appname.
And I would define the map data chmod 666 in spec so I could programitically remove the data.
I like your idea.
Hardly any experience with RPM though. I'll have to dive into that.
Sailfish people: please confirm if this is an allowed option.
Thanks.
R
wim
Post by Jonni Rainisto
________________________________________
From: devel-bounces at lists.sailfishos.org [devel-bounces at lists.sailfishos.org] on behalf of Wim de Vries [wsvries at xs4all.nl]
Sent: Thursday, January 09, 2014 10:05 AM
To: devel at lists.sailfishos.org
Subject: [SailfishDevel] How to install user (controlled) data files for my app avoiding /usr/share
Hi,
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).
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?
Thanks.
_______________________________________________
SailfishOS.org Devel mailing list
_______________________________________________
SailfishOS.org Devel mailing list
_______________________________________________
SailfishOS.org Devel mailing list
--
Ruslan Nigmatullin
_______________________________________________
SailfishOS.org Devel mailing list
winfried.dobbe
2014-01-09 12:17:23 UTC
Permalink
For other Linux distributions, the normal solution would be to package the
maps in a separate rpm file. Then if the user installs his/her own maps,
he can remove the standard maps package. Maybe you can do this as well?

Winfried
Post by Wim de Vries
Thanks.
Post by Jonni Rainisto
IMHO (Only my personal view, not official answer).
I would not copy readonly data to $XDG_CONFIG_HOME/$NAME, I would only
copy the readwrite parts off from usr/share/appname.
And I would define the map data chmod 666 in spec so I could
programitically remove the data.
I like your idea.
Hardly any experience with RPM though. I'll have to dive into that.
Sailfish people: please confirm if this is an allowed option.
Thanks.
R
wim
Post by Jonni Rainisto
________________________________________
From: devel-bounces at lists.sailfishos.org
[devel-bounces at lists.sailfishos.org] on behalf of Wim de Vries
[wsvries at xs4all.nl]
Sent: Thursday, January 09, 2014 10:05 AM
To: devel at lists.sailfishos.org
Subject: [SailfishDevel] How to install user (controlled) data files for
my app avoiding /usr/share
Hi,
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).
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?
Thanks.
_______________________________________________
SailfishOS.org Devel mailing list
_______________________________________________
SailfishOS.org Devel mailing list
_______________________________________________
SailfishOS.org Devel mailing list
Wim de Vries
2014-01-09 12:50:13 UTC
Permalink
Thanks.
Maybe that's the solution.
The default map would then be in rpm (in usr/share/....).
Deleting would require a rpm uninstall, while removing user maps (in
home/....) would be done from within the app. Might be a bit confusing,
but it is the only solution.
r
wim
Post by winfried.dobbe
For other Linux distributions, the normal solution would be to package the
maps in a separate rpm file. Then if the user installs his/her own maps,
he can remove the standard maps package. Maybe you can do this as well?
Winfried
Post by Wim de Vries
Thanks.
Post by Jonni Rainisto
IMHO (Only my personal view, not official answer).
I would not copy readonly data to $XDG_CONFIG_HOME/$NAME, I would only
copy the readwrite parts off from usr/share/appname.
And I would define the map data chmod 666 in spec so I could
programitically remove the data.
I like your idea.
Hardly any experience with RPM though. I'll have to dive into that.
Sailfish people: please confirm if this is an allowed option.
Thanks.
R
wim
Post by Jonni Rainisto
________________________________________
From: devel-bounces at lists.sailfishos.org
[devel-bounces at lists.sailfishos.org] on behalf of Wim de Vries
[wsvries at xs4all.nl]
Sent: Thursday, January 09, 2014 10:05 AM
To: devel at lists.sailfishos.org
Subject: [SailfishDevel] How to install user (controlled) data files for
my app avoiding /usr/share
Hi,
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).
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?
Thanks.
_______________________________________________
SailfishOS.org Devel mailing list
_______________________________________________
SailfishOS.org Devel mailing list
_______________________________________________
SailfishOS.org Devel mailing list
_______________________________________________
SailfishOS.org Devel mailing list
Wim de Vries
2014-01-09 12:39:07 UTC
Permalink
666 doesn't work, because all /usr/share (sub)dirs are /755:
///(rwxr-xr-x)/ The directory owner (i.c. root) has full access. All
others may list the directory, but cannot create files nor delete them.
This setting is common for directories that you wish to share with other
users.
/
r
wim
Post by Wim de Vries
Thanks.
Post by Jonni Rainisto
IMHO (Only my personal view, not official answer).
I would not copy readonly data to $XDG_CONFIG_HOME/$NAME, I would
only copy the readwrite parts off from usr/share/appname.
And I would define the map data chmod 666 in spec so I could
programitically remove the data.
I like your idea.
Hardly any experience with RPM though. I'll have to dive into that.
Sailfish people: please confirm if this is an allowed option.
Thanks.
R
wim
Post by Jonni Rainisto
________________________________________
From: devel-bounces at lists.sailfishos.org
[devel-bounces at lists.sailfishos.org] on behalf of Wim de Vries
[wsvries at xs4all.nl]
Sent: Thursday, January 09, 2014 10:05 AM
To: devel at lists.sailfishos.org
Subject: [SailfishDevel] How to install user (controlled) data files
for my app avoiding /usr/share
Hi,
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).
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?
Thanks.
_______________________________________________
SailfishOS.org Devel mailing list
_______________________________________________
SailfishOS.org Devel mailing list
_______________________________________________
SailfishOS.org Devel mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.sailfishos.org/pipermail/devel/attachments/20140109/48820329/attachment.html>
Thomas Perl
2014-01-09 12:50:26 UTC
Permalink
Hi,
Post by Wim de Vries
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).
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
Luciano Montanaro
2014-01-09 13:24:32 UTC
Permalink
And here you are:

https://together.jolla.com/question/12655/packaging-and-distributing-data-files-or-plugins/
Post by Thomas Perl
Hi,
Post by Wim de Vries
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).
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).
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
Wim de Vries
2014-01-09 22:27:33 UTC
Permalink
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
Post by Thomas Perl
Hi,
Post by Wim de Vries
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).
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).
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
Martin Kolman
2014-01-09 22:56:37 UTC
Permalink
Post by 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. :)
Post by Wim de Vries
r
wim
Post by Thomas Perl
Hi,
Post by Wim de Vries
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).
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).
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
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
Wim de Vries
2014-01-10 06:56:24 UTC
Permalink
Post by Martin Kolman
Post by 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.
Post by Martin Kolman
Post by Wim de Vries
r
wim
Post by Thomas Perl
Hi,
Post by Wim de Vries
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).
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).
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
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
Continue reading on narkive:
Loading...