Re: [GRASS-dev] packagers' guidance on inclusion of small dataset into the GRASS GIS installation
On 3/08/20 17:44, Sebastiaan Couwenberg wrote: On 8/3/20 4:59 PM, Moritz Lennert wrote: On 3/08/20 16:37, Sebastiaan Couwenberg wrote: On 8/3/20 4:16 PM, Moritz Lennert wrote: I have a small question concerning the best way to include a very small dataset into the distribution of GRASS GIS. We are currently working on the revamping of the GRASS GIS GUI startup experience, and have the currently proposed solution is that GRASS GIS could start up automatically creating a grassdata database and a default lat-long location which would contain just a simple NaturalEarth world country boundaries dataset. In some OS (e.g. MS Windows), such a demolocation is included in the distribution, but in Debian it is deleted before installation (IIUC what happens in the rules file at [1]). IIRC, Debian does normally not allow data to be distributed with binaries. One option would be to put the data directly into the Python code creating this location. Would that be acceptable for Debian ? What kind of solution would you recommend ? If the database can be built from source as part of the build process e.g. like proj.db in PROJ, it can be included in the package (assuming its license is DFSG compatible). Where is "this location"? If it's usr/lib/grassXY/demolocation, that's problematic because it's not writable by unprivileged users. A subdirectory of $XDG_DATA_HOME (e.g. $HOME/.local/share/grass) would be more suitable. Actually, the idea currently is that a new user without any grassdata will just get a grassdata directory automagically created during startup and the /usr/lib/grassXY/demolocation would simply be copied into that new grassdata directory. GRASS GIS would then directly start up into that location. So, the idea would be that during build /usr/lib/grassXY/demolocation is created. I don't know why the demolocation was never included in the package, looking at the repo history it has always been like that since way before I got involved. I've pushed a change to include the directory in the grass-core package: https://salsa.debian.org/debian-gis-team/grass/-/commit/faa570fd3357b1267d237fc0ee9b3386ce83479d That can be used as the source for the user writable copy. Thanks ! Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] packagers' guidance on inclusion of small dataset into the GRASS GIS installation
On 8/3/20 4:59 PM, Moritz Lennert wrote: > > > On 3/08/20 16:37, Sebastiaan Couwenberg wrote: >> On 8/3/20 4:16 PM, Moritz Lennert wrote: >>> I have a small question concerning the best way to include a very small >>> dataset into the distribution of GRASS GIS. We are currently working on >>> the revamping of the GRASS GIS GUI startup experience, and have the >>> currently proposed solution is that GRASS GIS could start up >>> automatically creating a grassdata database and a default lat-long >>> location which would contain just a simple NaturalEarth world country >>> boundaries dataset. >>> >>> In some OS (e.g. MS Windows), such a demolocation is included in the >>> distribution, but in Debian it is deleted before installation (IIUC what >>> happens in the rules file at [1]). >>> >>> IIRC, Debian does normally not allow data to be distributed with >>> binaries. One option would be to put the data directly into the Python >>> code creating this location. Would that be acceptable for Debian ? What >>> kind of solution would you recommend ? >> >> If the database can be built from source as part of the build process >> e.g. like proj.db in PROJ, it can be included in the package (assuming >> its license is DFSG compatible). >> >> Where is "this location"? >> >> If it's usr/lib/grassXY/demolocation, that's problematic because it's >> not writable by unprivileged users. A subdirectory of $XDG_DATA_HOME >> (e.g. $HOME/.local/share/grass) would be more suitable. > > Actually, the idea currently is that a new user without any grassdata > will just get a grassdata directory automagically created during startup > and the /usr/lib/grassXY/demolocation would simply be copied into that > new grassdata directory. GRASS GIS would then directly start up into > that location. > > So, the idea would be that during build /usr/lib/grassXY/demolocation is > created. I don't know why the demolocation was never included in the package, looking at the repo history it has always been like that since way before I got involved. I've pushed a change to include the directory in the grass-core package: https://salsa.debian.org/debian-gis-team/grass/-/commit/faa570fd3357b1267d237fc0ee9b3386ce83479d That can be used as the source for the user writable copy. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] packagers' guidance on inclusion of small dataset into the GRASS GIS installation
On 3/08/20 16:37, Sebastiaan Couwenberg wrote: On 8/3/20 4:16 PM, Moritz Lennert wrote: I have a small question concerning the best way to include a very small dataset into the distribution of GRASS GIS. We are currently working on the revamping of the GRASS GIS GUI startup experience, and have the currently proposed solution is that GRASS GIS could start up automatically creating a grassdata database and a default lat-long location which would contain just a simple NaturalEarth world country boundaries dataset. In some OS (e.g. MS Windows), such a demolocation is included in the distribution, but in Debian it is deleted before installation (IIUC what happens in the rules file at [1]). IIRC, Debian does normally not allow data to be distributed with binaries. One option would be to put the data directly into the Python code creating this location. Would that be acceptable for Debian ? What kind of solution would you recommend ? If the database can be built from source as part of the build process e.g. like proj.db in PROJ, it can be included in the package (assuming its license is DFSG compatible). Where is "this location"? If it's usr/lib/grassXY/demolocation, that's problematic because it's not writable by unprivileged users. A subdirectory of $XDG_DATA_HOME (e.g. $HOME/.local/share/grass) would be more suitable. Actually, the idea currently is that a new user without any grassdata will just get a grassdata directory automagically created during startup and the /usr/lib/grassXY/demolocation would simply be copied into that new grassdata directory. GRASS GIS would then directly start up into that location. So, the idea would be that during build /usr/lib/grassXY/demolocation is created. Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] packagers' guidance on inclusion of small dataset into the GRASS GIS installation
On 8/3/20 4:16 PM, Moritz Lennert wrote: > I have a small question concerning the best way to include a very small > dataset into the distribution of GRASS GIS. We are currently working on > the revamping of the GRASS GIS GUI startup experience, and have the > currently proposed solution is that GRASS GIS could start up > automatically creating a grassdata database and a default lat-long > location which would contain just a simple NaturalEarth world country > boundaries dataset. > > In some OS (e.g. MS Windows), such a demolocation is included in the > distribution, but in Debian it is deleted before installation (IIUC what > happens in the rules file at [1]). > > IIRC, Debian does normally not allow data to be distributed with > binaries. One option would be to put the data directly into the Python > code creating this location. Would that be acceptable for Debian ? What > kind of solution would you recommend ? If the database can be built from source as part of the build process e.g. like proj.db in PROJ, it can be included in the package (assuming its license is DFSG compatible). Where is "this location"? If it's usr/lib/grassXY/demolocation, that's problematic because it's not writable by unprivileged users. A subdirectory of $XDG_DATA_HOME (e.g. $HOME/.local/share/grass) would be more suitable. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
