Fellow GRASS users
Markus Neteler, Scott Mitchell, and I exchanged several emails over how to package and distribute Mac binaries for GRASS. This discussion raises some interesting issues and questions for the GRASS user community. Markus suggested that it would be good to involve more people in the discussion, and both Scott and I agree. I am forwarding some of the more general commentary as a starting point in the discussion. (which began with Scott and Markus making arrangements on posting Scott's recently compiled Mac binaries for GRASS 5.3, and a note on the new package of binaries posted by Lorenzo Moretti). All these are worthy and supportable efforts. The discussion is over how to most effectively package, post, and distribute GRASS.
Sorry for the length. We had already written quite a bit for a Friday when we realized that we were discussing a larger issue than posting a file and could benefit from a broader discussion. Maybe interested folks can take it home and read it over the weekend.
Michael Barton
______________________________
Michael Barton, Professor & Curator
Department of Anthropology
Arizona State University
Tempe, AZ 85287-2402
USA
voice: 480-965-6262; fax: 480-965-7671
-messages in reverse chronological order
From: Scott Mitchell <smitch@mac.com>
Date: Fri Mar 5, 2004 10:02:23 AM America/Phoenix
To: Markus Neteler <neteler@itc.it>
Cc: "Kirk R. Wythers" <kwythers@umn.edu>, Michael Barton <michael.barton@asu.edu>
Subject: Re: uploading your binariesJust quick replies, as I really should do some other work for a while...
(1) The alternate location of Lorenzo's build should not matter, and I see your point of it being familiar to users. I used alternative locations for GRASS for years on some Suns I used to take care of, and never had a problem. Just needs to be built with the paths specified.
(2) Making an up to date fink package would be yet another relatively painless way to install. Something I'd love to investigate some day but so far no time.
(3) I know that on some web sites I have seen that the Apple .pkg way of installing things is a big security hole, and some knowledgeable people will refuse to install anything distributed by anyone besides Apple in this format as a result. I don't know any details, but I can see that as one reason why alternate formats are always good. On the other hand, your discussions of the attraction of one double clickable file for the majority of users is quite valid.
(4) I am working on cleaning up the Mac help page now to deal with some of all this confusion and will try to keep on top of that. Will also take a look at the README files in the new download directory structure.
Cheers,
ScottFrom: Markus Neteler <neteler@itc.it>
Date: Fri Mar 5, 2004 9:54:10 AM America/Phoenix
To: Michael Barton <michael.barton@asu.edu>
Cc: Scott Mitchell <smitch@mac.com>, "Kirk R. Wythers" <kwythers@umn.edu>
Subject: Re: uploading your binariesOn Fri, Mar 05, 2004 at 09:39:11AM -0700, Michael Barton wrote:
I looked at Lorenzo's site Wednesday and Thursday, before it went down,
and emailed him for some clarifications.Here is what it looks like AFAICT. I have not yet downloaded it. I went
to do so yesterday and the site was down. When I looked at it a few
hours earlier, it is very well documented.A colleague at University here told me, that he was
able to install it in 5 minutes. Sounds like the right
direction.He has a *.pkg installation of GRASS 5.3, GRASS 5.7, the Spearfish
sample data set, and PostgreSQL. The GRASS installation includes all
the needed files to run grass (tcltk, gdal, proj, and a couple others)
except X11. It is in a Standard Mac OSX *.pkg format. That is,
installation requires only double-clicking the *.pkg file on the Mac
desktop. The only thing I can see that is non-standard is that he
installs it into the /Applications directory. This is where the Mac
wants to put all applications. All Aqua things go there and a few X11
apps have started showing up there. I don't know what the implications
of this might be for using GRASS (maybe none if it is compiled
correctly for this location???). BTW, Fink installs it in /sw/shared
which is really non-standard.For myself, this is the direction I personally think GRASS needs to go
to make it accessible to a wider GIS audience. However, I don't know...1) whether or not Lorenzo's package wor--especially tcltk (At least one
student here did download it and is planning to install it. So maybe
we'll see.)2) what the implications are to the non-standard installation location.
The same package procedure could be used to put GRASS in /usr/local.The downside of the standard location is that it is by default hidden
on the Mac, while /Applications is not. Also, you cannot make any
changes to /usr/local without root access (i.e., I have to use sudo to
do anything there). At least I think those are disadvantages.Maybe this should be discussed in 'grass5'?
FWIW, I would vote (with Scott I think) to provide a link to Lorenzo's
site to see how it goes for nowThe link is there for some weeks.
and put a new 'standard' binary up on
the main GRASS site.Now also there. Maybe the link should be mentioned as
well in the new 5.3 Mac README in the binary directory.However, I think in the future, we should try to
move away from an installation that requires users to open a terminal
window and call a shell script, then do a similar or even more complex
installation of libraries needed get GRASS to run. While it seems fine
to make this kind of custom installation available to those who want to
do it, I personally can't see any reasons to require it of the majority
of GRASS users.I would appreciate to see .deb, .rpm for Debian, Redhat, Suse, Mandrake.
But nobody wants to contribute... That's why we still have the
script solution.It seems to me that the eventual goal of distributing GRASS is to make
an excellent piece of software available to people who need to use GIS.
In trying to use GRASS in my graduate class this Spring, about half the
students who initially wanted to use it gave up after fighting with
installation difficulties.I can imagine...
Those that persisted and made it through the
installation have been very happy with GRASS (except one guy who has a
Windows 98 workstation). It seems that an installation that filters out
50% of the potential users is problematic.Maybe like that:
- 50% installation problems
- 30% launching GRASS the *first* time
- 20% all other problemsAn unfortunate proportion, definitely the 50% installation troubles
should be eliminated. People just want (!) to click, at least
for installation. So with RPMs etc it were fine, but if not provided...Well that's probably far too much pontificating on my part
I did
want to put in my 2 cents worth (I guess that's 1.5 cents given the
value of the dollar against the Euro now).I'm already looking forward the new tcltkgrass!
I also can't offer enough appreciation to you folks who have kept this
project alive and kicking into the 21st Century.Hope we don't kick it out of space (let's assume it's not flat).
Thanks
Markus
Markus
Begin forwarded message:
From: Michael Barton <michael.barton@asu.edu>
Date: Fri Mar 5, 2004 9:39:11 AM America/Phoenix
To: Scott Mitchell <smitch@mac.com>
Cc: Markus Neteler <neteler@itc.it>, "Kirk R. Wythers" <kwythers@umn.edu>
Subject: Re: uploading your binariesI looked at Lorenzo's site Wednesday and Thursday, before it went down, and emailed him for some clarifications.
Here is what it looks like AFAICT. I have not yet downloaded it. I went to do so yesterday and the site was down. When I looked at it a few hours earlier, it is very well documented.
He has a *.pkg installation of GRASS 5.3, GRASS 5.7, the Spearfish sample data set, and PostgreSQL. The GRASS installation includes all the needed files to run grass (tcltk, gdal, proj, and a couple others) except X11. It is in a Standard Mac OSX *.pkg format. That is, installation requires only double-clicking the *.pkg file on the Mac desktop. The only thing I can see that is non-standard is that he installs it into the /Applications directory. This is where the Mac wants to put all applications. All Aqua things go there and a few X11 apps have started showing up there. I don't know what the implications of this might be for using GRASS (maybe none if it is compiled correctly for this location???). BTW, Fink installs it in /sw/shared which is really non-standard.
For myself, this is the direction I personally think GRASS needs to go to make it accessible to a wider GIS audience. However, I don't > know...
1) whether or not Lorenzo's package wor--especially tcltk (At least one student here did download it and is planning to install it. So maybe we'll see.)
2) what the implications are to the non-standard installation location. The same package procedure could be used to put GRASS in /usr/local.
The downside of the standard location is that it is by default hidden on the Mac, while /Applications is not. Also, you cannot make any changes to /usr/local without root access (i.e., I have to use sudo to do anything there). At least I think those are disadvantages.
FWIW, I would vote (with Scott I think) to provide a link to Lorenzo's site to see how it goes for now and put a new 'standard' binary up on the main GRASS site. However, I think in the future, we should try to move away from an installation that requires users to open a terminal window and call a shell script, then do a similar or even more complex installation of libraries needed get GRASS to run. While it seems fine to make this kind of custom installation available to those who want to do it, I personally can't see any reasons to require it of the majority of GRASS users.
It seems to me that the eventual goal of distributing GRASS is to make an excellent piece of software available to people who need to use GIS. In trying to use GRASS in my graduate class this Spring, about half the students who initially wanted to use it gave up after fighting with installation difficulties. Those that persisted and made it through the installation have been very happy with GRASS (except one guy who has a Windows 98 workstation). It seems that an installation that filters out 50% of the potential users is problematic.
Well that's probably far too much pontificating on my part
I also can't offer enough appreciation to you folks who have kept this project alive and kicking into the 21st Century.
Cheers,
MichaelOn Friday, March 5, 2004, at 09:04 AM, Scott Mitchell wrote:
Sure, and I wanted to double check before writing it because the bit about not being able to install where you want may have changed with his latest release, but as you found, his site is currently down. The basic idea is still the same...
Cheers,
ScottOn 5-Mar-04, at 10:57, Markus Neteler wrote:
installed with as close as possible the same procedure as other binary
releases from the official sites.OK, I wasn't aware that Lorenzo is including so much stuff (I didn't
check).------
Scott W. Mitchell Scott_Mitchell@carleton.ca
Department of Geography and Environmental Studies
Carleton University, B349 Loeb Building (Office A209)
1125 Colonel By Drive, Ottawa, ON Canada K1S 5B6
+1-613-520-2600 ext 2695 Fax: 1-613-520-4301______________________________
Michael Barton, Professor & Curator
Department of Anthropology
Arizona State University
Tempe, AZ 85287-2402
USAvoice: 480-965-6262; fax: 480-965-7671
From: Scott Mitchell <smitch@mac.com>
Date: Fri Mar 5, 2004 8:54:06 AM America/Phoenix
To: Markus Neteler <neteler@itc.it>
Cc: "Kirk R. Wythers" <kwythers@umn.edu>, Michael Barton <michael.barton@asu.edu>
Subject: Re: uploading your binariesMy only concern with Lorenzo's solution is that it is not "standard", in that (1) it includes all sorts of other packages, and (2) it forces files to install into particular locations. I am quite happy that he has done the work, and intend to link to it from our pages, but I'm hoping to also have an "official" binary release that is as made and installed with as close as possible the same procedure as other binary releases from the official sites.
So I was thinking we could have the one in the "normal" location which required fink (or alternatives, for the more advanced users), and I have been working on another "cleaner" one which will hopefully get rid of the fink dependency as well (which could either be on the GRASS site or be pointed to elsewhere), and ALSO our page of explanations with pointers to alternative solutions.
I am quite willing to be swayed into alternative arrangements, but this seemed to be closest to the way other platforms are handled, and true to the sentiments raised on the list recently, especially by Glynn, about distributing as little that is not GRASS itself as possible.
Reasonable?
ScottOn 5-Mar-04, at 10:35, Markus Neteler wrote:
Scott,
I'm of course willing to move the binaries from incoming/ into
the web space. But AFAIK the Mac binaries from L. from Bologna
(recently announced in grassuser) do not need FINK.I am a bit confused with all these versions around.
What should I do?Here the link:
http://wwwamb.bologna.enea.it/forgrass/(maybe he has 5.7 only, cannot open the site at time)
Thanks for clarifications,
(sorry for my Mac-ignorance)Markus
On Wed, Mar 03, 2004 at 10:40:17AM -0500, Scott Mitchell wrote:
Ok, I have a binary dist built of GRASS5.3-cvs that works for me, it
has libgdal 1.2.0 included, compiled on a "Panther" (OS 10.3.2)
machine. It tests fine on a "Jaguar" machine (10.2.6?), too, but I've
confirmed that it still requires fink.I'm uploading this now to grass.itc.it, 3 files (the usual two plus a
README), and they are also available under
http://bouteloua.erin.utoronto.ca/~smitch/Markus, when they're uploaded, can you please put them in the Mac
binaries area? I will also make sure there are some files in there
explaining the requirements.I've been working on getting an even more portable version that
wouldn't require fink... as you may have seen on the list, we should be
able to get around the Tcl/Tk problem by either embedding it in the
GRASS distribution or by distributing a separate tarball to install,
but I found in my testing that getting rid of that dependency just
exposed another - when I "hide" fink on my system, GRASS can't start
because the version of another library (curses) that it finds in the
system directory doesn't match the version it was compiled against
(from fink). So I'll have to try keeping fink "more out of the
picture" for the compilations, but this will take more time and
experimentation.Cheers,
ScottOn 2-Mar-04, at 13:11, Michael Barton wrote:
Scott,
Do you have any idea where to get a packaged version of tcltk that we
could include in a Mac OSX package to avoid having to upload fink (as
much as I like fink)?Michael
On Tuesday, March 2, 2004, at 11:04 AM, Scott Mitchell wrote:
The version I now have should be at least clean from the
internationalization library, and now I also have some on my portable
that are compiled against GDAL1.2.0 ... so I guess it would make
sense for me to upload those ones, after the class I'm just now
heading out to teach. I'm not sure how big the change is in GDAL,
but vaguely recall a list message from Markus advising someone to use
it, so there may be something important.Cheers,
ScottOn 2-Mar-04, at 12:54, Michael Barton wrote:
Scott,
I agree with you on all points. What do you think? Should I upload
the binaries I now have from you (along with a note saying that you
need a Fink library and tcltk) or wait until you do your 'clean'
binaries?Michael
On Monday, March 1, 2004, at 06:55 PM, Scott Mitchell wrote:
From: Scott Mitchell <smitch@mac.com>
Date: Mon Mar 1, 2004 6:55:30 PM America/Phoenix
To: Michael Barton <michael.barton@asu.edu>
Subject: Re: uploading your binaries
Attachments: There is 1 attachmentYeah, I have done that in the past, it works OK - I uploaded some
5.0.2 binaries at one point. At the time, Markus asked that at
least one other person confirm that they work before uploading -
seems like a good procedure. Because the upload server doesn't let
you see the directory that you're uploading to, you have to keep
track of which files are already uploaded when dealing with more
than one - it doesn't let you overwrite. This probably won't be an
issue any more, I suppose - it was then because the same file name
was used for different versions of the binary tar files and script
files but now for >5.3.x the release info and platform both get
into the names of both files.I agree with Paul Kelly that it's important to carefully building
them according to the instructions, and document exceptions - that
helps get the best help when portability issues do arise. I
actually built a new bindist of 5.3 on OS X last weekend, paying
attention to some of the recent notes on shared libraries, and was
going to make them available - but then realized that I had failed
to consult the release_rules file when building, so have been
meaning to check it out and rebuild if necessary. Will get on
that.Having said that, especially for the Mac platform, it could be
useful to have access to "other" unofficial builds, for the reasons
and with the disclaimers that you've suggested in your list post.
I get the sense that the "larger" community wants the distributed
files that are on the main download matrix to "follow the rules"
exactly, but there would be no trouble linking to other ones from,
for example the Mac info page - I should step up the cleaning up of
that and make the links from other pages.Cheers,
Scott______________________________
Michael Barton, Professor & Curator
Department of Anthropology
Arizona State University
Tempe, AZ 85287-2402
USAvoice: 480-965-6262; fax: 480-965-7671
------
Scott W. Mitchell Scott_Mitchell@carleton.ca
Department of Geography and Environmental Studies
Carleton University, B349 Loeb Building (Office A209)
1125 Colonel By Drive, Ottawa, ON Canada K1S 5B6
+1-613-520-2600 ext 2695 Fax: 1-613-520-4301______________________________
Michael Barton, Professor & Curator
Department of Anthropology
Arizona State University
Tempe, AZ 85287-2402
USAvoice: 480-965-6262; fax: 480-965-7671
------
Scott W. Mitchell Scott_Mitchell@carleton.ca
Department of Geography and Environmental Studies
Carleton University, B349 Loeb Building (Office A209)
1125 Colonel By Drive, Ottawa, ON Canada K1S 5B6
+1-613-520-2600 ext 2695 Fax: 1-613-520-4301--
Markus Neteler <neteler itc it> http://mpa.itc.it
ITC-irst - Centro per la Ricerca Scientifica e Tecnologica
MPBA - Predictive Models for Biol. & Environ. Data Analysis
Via Sommarive, 18 - 38050 Povo (Trento), Italy------
Scott W. Mitchell Scott_Mitchell@carleton.ca
Department of Geography and Environmental Studies
Carleton University, B349 Loeb Building (Office A209)
1125 Colonel By Drive, Ottawa, ON Canada K1S 5B6
+1-613-520-2600 ext 2695 Fax: 1-613-520-4301