Hi,
Is it possible to install (any) development / test version of GRASS (trunk or 7.4.0RC2) in parallel to the stable version (GRASS 7.2) from UbunutGIS both at the same machine?
I know both can co-exist when I compile from source, but a binary package might come in handy in some cases…
GRASS website 1 says GRASS 7 can be installed in parallel to GRASS 6. Does that mean that e.g. 7.4 in parallel to 7.2 is not possible?
Cheers
Stefan
On Dec 14, 2017 12:48 PM, “Stefan Blumentrath” <Stefan.Blumentrath@nina.no> wrote:
Hi,
Is it possible to install (any) development / test version of GRASS (trunk or 7.4.0RC2) in parallel to the stable version (GRASS 7.2) from UbunutGIS both at the same machine?
Sure! Since the names are different, no problem.
I know both can co-exist when I compile from source, but a binary package might come in handy in some cases…
I commonly have several versions installed and running.
Limitation: it is possible with self compiled GRASS GIS. Any package manager would substitute…
GRASS website [1] says GRASS 7 can be installed in parallel to GRASS 6. Does that mean that e.g. 7.4 in parallel to 7.2 is not possible?
It is possible if you compile yourself.
(I’d appreciate help to improve/redo the web site, but that’s a different topic)
Cheers
Markus
Hi Markus,
Many thanks for the swift reply and the clarification!
Will think about website improvements and come back to you…
I would assume, being able to have package based installations of test versions in parallel to the current stable would make it easier for casual testers or people interested in certain features of development versions to get more involved in early testing in general…
Meaning, if that is technically possible it could be a good thing to do, in order to increase number of testers and early adopters… Just a thought…
Cheers
Stefan
Hi Stefan,
On Thu, Dec 14, 2017 at 1:26 PM, Stefan Blumentrath
<Stefan.Blumentrath@nina.no> wrote:
Hi Markus,
Many thanks for the swift reply and the clarification!
Will think about website improvements and come back to you…
Great!
I would assume, being able to have package based installations of test
versions in parallel to the current stable would make it easier for casual
testers or people interested in certain features of development versions to
get more involved in early testing in general…Meaning, if that is technically possible it could be a good thing to do, in
order to increase number of testers and early adopters… Just a thought…
It is there for many years 
Called weekly binary snapshots. Or I
don't get what you mean...
Cheers
Markus
--
Markus Neteler, PhD
http://www.mundialis.de - free data with free software
http://grass.osgeo.org
http://courses.neteler.org/blog
On Thu, 14 Dec 2017, Stefan Blumentrath wrote:
I would assume, being able to have package based installations of test
versions in parallel to the current stable would make it easier for casual
testers or people interested in certain features of development versions
to get more involved in early testing in general… Meaning, if that is
technically possible it could be a good thing to do, in order to increase
number of testers and early adopters… Just a thought…
Stefan,
I used to run the svn trunk version along with the stable version but
finally dropped the latter. Running the latest release code I've found a few
bugs or inconsistencies and the developers have quickly applied patches.
Sometimes within the hour. While I'm not using all modules or different data
types when I do find something that needs fixing I make the developers aware
of the problem so others don't encounter it.
Regards,
Rich
On 14/12/17 13:49, Markus Neteler wrote:
Hi Stefan,
On Thu, Dec 14, 2017 at 1:26 PM, Stefan Blumentrath
<Stefan.Blumentrath@nina.no> wrote:Hi Markus,
Many thanks for the swift reply and the clarification!
Will think about website improvements and come back to you…
Great!
I would assume, being able to have package based installations of test
versions in parallel to the current stable would make it easier for casual
testers or people interested in certain features of development versions to
get more involved in early testing in general…Meaning, if that is technically possible it could be a good thing to do, in
order to increase number of testers and early adopters… Just a thought…It is there for many years
don't get what you mean...
I think Stefan means distribution packages.
Theoretically this is possible. One could create a specific "grass-trunk" package which is packaged in a way to not conflict with the official stable grass version.
However, I think most distribution packagers are already very busy just handling the stable packages. The difficulty with creating such a grass-trunk package would be that it would have to be repackaged regularly (daily), but this means that whoever used it would have to have exactly the same versions of dependecy packages installed on their machine as on the package build machine.
And then, which distribution and which version of a distribution should we make packages for ?
In summary: if you are willing to create such a package against a clearly defined version of a distribution than this would be great, but I don't think you can count on either the core developers of GRASS, nor the packagers of different distributions for doing this.
Moritz
Hi Moritz,
(warming this post up again ...).
I see your point!
And I am aware, that dependencies might be changed in development versions. QGIS has some nightly builds e.g. with ubuntugis dependencies.
Maybe snap could be useful? There does not seem to be a snap for GRASS yet:
https://snapcraft.io/search?q=grass
If you guys think this is of interest, I could have a look at it in Bonn (and maybe join forces with QGIS project if the relevant people for the QGIS snap [1,2] are in Bonn too).
I would also consider contributing to packaging, but I have no experience with that. So, maybe Martin (as we are on Ubuntu), we can have a short chat in Bonn to see if I can be of help there...
Looking forward to seeing you in Bonn!
Cheers
Stefan
1: https://github.com/Wollac/snap-qgis
2: https://github.com/elopio/QGIS/blob/snapcraft/snapcraft.yaml
-----Original Message-----
From: Moritz Lennert [mailto:mlennert@club.worldonline.be]
Sent: torsdag 14. desember 2017 15.59
I think Stefan means distribution packages.
Theoretically this is possible. One could create a specific "grass-trunk" package which is packaged in a way to not conflict with the official stable grass version.
However, I think most distribution packagers are already very busy just handling the stable packages. The difficulty with creating such a grass-trunk package would be that it would have to be repackaged regularly (daily),
but this means that whoever used it would have to have exactly the same versions of dependecy packages installed on their machine as on the package build machine.
And then, which distribution and which version of a distribution should we make packages for ?
In summary: if you are willing to create such a package against a clearly defined version of a distribution than this would be great, but I don't think you can count on either the core developers of GRASS, nor the packagers of different distributions for doing this.
Moritz
On 13/03/18 09:30, Stefan Blumentrath wrote:
Hi Moritz,
(warming this post up again ...).
I see your point!
And I am aware, that dependencies might be changed in development versions. QGIS has some nightly builds e.g. with ubuntugis dependencies.Maybe snap could be useful? There does not seem to be a snap for GRASS yet:
https://snapcraft.io/search?q=grassIf you guys think this is of interest, I could have a look at it in Bonn (and maybe join forces with QGIS project if the relevant people for the QGIS snap [1,2] are in Bonn too).
I didn't know snap, but somehow, I have the feeling that with Docker, snap, etc we are going back to a world where each software package installs each of its dependencies separately, leading to the same library being installed multiple times on one machine. I guess cheap disk space and containerization makes this a bit less of a problem, but it still just does not feel right when you come from the beautiful world of coordinated packaging in Debian and others distros.
Moritz
Fully agreed!
Main advantage I would see with snap is that it is supposed to be distro independent and that it possibly is easier with packages for different GRASS versions in parallel (again I do not have any experience with packaging).
Cheers,
Stefan
From: Moritz Lennert mlennert@club.worldonline.be
Sent: Tuesday, March 13, 2018 10:06:57 AM
To: Stefan Blumentrath; Markus Neteler
Cc: GRASS user list
Subject: Re: [GRASS-user] Install GRASS stable and experimental in parallel
On 13/03/18 09:30, Stefan Blumentrath wrote:
Hi Moritz,
(warming this post up again …).
I see your point!
And I am aware, that dependencies might be changed in development versions. QGIS has some nightly builds e.g. with ubuntugis dependencies.Maybe snap could be useful? There does not seem to be a snap for GRASS yet:
https://snapcraft.io/search?q=grassIf you guys think this is of interest, I could have a look at it in Bonn (and maybe join forces with QGIS project if the relevant people for the QGIS snap [1,2] are in Bonn too).
I didn’t know snap, but somehow, I have the feeling that with Docker,
snap, etc we are going back to a world where each software package
installs each of its dependencies separately, leading to the same
library being installed multiple times on one machine. I guess cheap
disk space and containerization makes this a bit less of a problem, but
it still just does not feel right when you come from the beautiful world
of coordinated packaging in Debian and others distros.
Moritz