Dear Silke,
I was just thinking It'd be easier for who already has the original tar.gz to download a diff. instead of the entire tar.gz from my relatively slow connection. When I will have access to my pc again, I'll do that in first time. The catch my workstation has the PSU broken and right now I'm using my brother's one. I hope to get it fixed for today afternoon. So no problems about that. (Hoping the motherboard has nothing to do with it).
About my package, just to mention it's strongly based on Federico's work, so he's completely free to use it as a base, to replace the present package. I guess it will be a little hard knowing how restrictive debian policies are. In any case, no problems about me. Unfortunately I didn't contact Federico directly, I hope he's reading now, and that he has read my previous message, where I gave him the credits for this package, he surely deserves them.
Please note I could lose some time reading and answering messages (At least until I get my pc fixed).
Regards, Giuseppe Dia
Patches to my debian packages are always welcome. i just replaced my
laptop (that broke last week) and i am starting to work on grass again.
can you please send me the diffs? right now i am working on pg support
(that did not worked with pg 7.3) and splitting documentation in
separate package).
ciao,
federico
Scavenging the mail folder uncovered Giuseppe Dia's letter:
About my package, just to mention it's strongly based on Federico's work,
so he's completely free to use it as a base, to replace the present package.
I guess it will be a little hard knowing how restrictive debian policies
are. In any case, no problems about me. Unfortunately I didn't contact
Federico directly, I hope he's reading now, and that he has read my previous
message, where I gave him the credits for this package, he surely deserves
them. > Please note I could lose some time reading and answering messages
(At least until I get my pc fixed). > Regards, Giuseppe Dia > > >
--
Federico Di Gregorio
Debian GNU/Linux Developer & Italian Press Contact fog@debian.org
Those who do not study Lisp are doomed to reimplement it. Poorly.
-- from Karl M. Hegbloom .signature
On Thu, 10 Jul 2003, Federico Di Gregorio wrote:
...
(that did not worked with pg 7.3) and splitting documentation in
separate package).
I noticed on the debian web site that someone had commented about putting
the GRASS man pages in a standard system directory so they could be read
from the command line with the man command. I don't think this is right as
they are supposed to be read within GRASS with the g.manual command. I
don't know what the official policy on this was and wondered how other
people read their man pages and does anybody install them in the
standard system directories?
Not very important at all but it was just a thought that crossed my mind
and wondered what people think about it?
Paul Kelly
Il gio, 2003-07-10 alle 11:45, Paul Kelly ha scritto:
[snip]
I noticed on the debian web site that someone had commented about putting
the GRASS man pages in a standard system directory so they could be read
from the command line with the man command. I don't think this is right as
they are supposed to be read within GRASS with the g.manual command. I
don't know what the official policy on this was and wondered how other
people read their man pages and does anybody install them in the
standard system directories?
Not very important at all but it was just a thought that crossed my mind
and wondered what people think about it?
i don't care that much either, but i think it can be usefull to read
grass manpages without launching grass. if i can move the manpages to
the default location without disturbing (or with a minor patch) to
g.manual i'll do, unless there is strong objection from you grass
people.
federico
Paul Kelly wrote:
> (that did not worked with pg 7.3) and splitting documentation in
> separate package).
I noticed on the debian web site that someone had commented about putting
the GRASS man pages in a standard system directory so they could be read
from the command line with the man command. I don't think this is right as
they are supposed to be read within GRASS with the g.manual command. I
don't know what the official policy on this was and wondered how other
people read their man pages and does anybody install them in the
standard system directories?
I keep them under $GISBASE, but add $GISBASE/man to MANPATH, so that
they are readable outside of GRASS. I normally use XEmacs for reading
manpages, and having to use the "man" program (via g.manual) within an
xterm would be a nuisance. The same issue would apply to reading
manpages with Xman etc.
The manpages probably shouldn't be installed in /usr/man or
/usr/local/man. There are so many of them, and some of them have names
which would conflict with existing programs; e.g. GRASS has a
"display" manpage which lists the various d.* commands, but
ImageMagick also has a "display" program with a corresponding manpage.
Similarly, if we were to start installing a full set of libraries
(rather than just libgis and libdatetime), either they should go into
their own directory or they should have a prefix (i.e. libgrass_gis).
Also, for 5.1, it might be worth giving all of the GRASS headers a
prefix directory, i.e.
#include <grass/gis.h>
The headers themselves could then go into /usr/include/grass without
needing to use any -I switches (cf. the number of queries we get
regarding --with-postgres-includes).
--
Glynn Clements <glynn.clements@virgin.net>
Il gio, 2003-07-10 alle 16:58, Glynn Clements ha scritto:
[snip]
> standard system directories?
I keep them under $GISBASE, but add $GISBASE/man to MANPATH, so that
they are readable outside of GRASS. I normally use XEmacs for reading
manpages, and having to use the "man" program (via g.manual) within an
xterm would be a nuisance. The same issue would apply to reading
manpages with Xman etc.
The manpages probably shouldn't be installed in /usr/man or
/usr/local/man. There are so many of them, and some of them have names
which would conflict with existing programs; e.g. GRASS has a
"display" manpage which lists the various d.* commands, but
ImageMagick also has a "display" program with a corresponding manpage.
this is not a problem, debian uses manpage extensions. all manpages from
grass package will have the Ngrass extension (N = 1 ..)
Similarly, if we were to start installing a full set of libraries
(rather than just libgis and libdatetime), either they should go into
their own directory or they should have a prefix (i.e. libgrass_gis).
Also, for 5.1, it might be worth giving all of the GRASS headers a
prefix directory, i.e.
#include <grass/gis.h>
The headers themselves could then go into /usr/include/grass without
needing to use any -I switches (cf. the number of queries we get
regarding --with-postgres-includes).
that would be very nice on development boxes with very cramped
/usr/include directories.