[GRASS-dev] Re: [DebianGIS] build-indep for grass and other issues.

Francesco P. Lovergine wrote:

In order to 'solve' the build-indep issue of grass, I would introduce
a special target to build once documentation on the maintainer box
and create a uuencoded tarball for the debian/ dir.

I understand the 'build-indep' problem to be that with debian's 11 or so
architectures, it is very wasteful to have 11 copies of GRASS help pages
in 11 packages on the package mirrors, so Debian prefers to move that
into a grass-doc package and only keep 1 copy of that for all platforms,
with 11 smaller binary packages. ?

One more issue is the confused and not too policy-compliant
/usr/lib/grass/etc/ directory which contains a mess of various
files/binaries. The only decent way to manage that could be writing a
script which autoclassifies files and move them in the right package
and directories, leaving a symlink in etc for compatibility with the
grass tree.

All should go into 6.2 and experimental of course.

Ideas?

would /usr/lib/grass/share/ be any better? For GRASS it has been nice to
keep all files installed in 1 dir instead of scattered throughout
system. This way we can keep multiple versions on the same machine
without mixing problems. (But debian policy doesn't like that..)

can there be no "etc/" dirs put anywhere?

PS: I would like also grass folks find a plain and clear policy for
paths one day or another, keeping arch-dep and arch-indep things
separated :slight_smile:

I think $GISBASE/etc/ is hardcoded in a lot of places, but it could be
changed. I think this is too huge a patch for a stable 6.2 we could
support.

I am not against a cleanup of etc/, I think it is a good idea, but it
will only happen in GRASS's CVS devel branch, not 6.2.

As a first pass, we could move support binary progs into
support/$module/, scripts to scripts/, proj/, gui/, etc.

Hamish

Francesco P. Lovergine wrote:

> I understand the 'build-indep' problem to be that with debian's 11
> or so architectures, it is very wasteful to have 11 copies of GRASS
> help pages in 11 packages on the package mirrors, so Debian prefers
> to move that into a grass-doc package and only keep 1 copy of that
> for all platforms, with 11 smaller binary packages. ?
>

Yep.

..

> would /usr/lib/grass/share/ be any better? For GRASS it has been
> nice to keep all files installed in 1 dir instead of scattered
> throughout system. This way we can keep multiple versions on the
> same machine without mixing problems. (But debian policy doesn't
> like that..)
>
> can there be no "etc/" dirs put anywhere?
>

The point is that etc/ currently has a mix of arch-dep and arch-indep
things all mixed together. At least sanitizing this thing could be
nice.

how about one of these:

$GISBASE/share/$MODULE_NAME/binary.app

$GISBASE/support/$MODULE_NAME/binary.app

$GISBASE/bin/support/$MODULE_NAME/binary.app

$GISBASE/etc/support/$MODULE_NAME/binary.app

$GISBASE/etc/bin/$MODULE_NAME/binary.app

?

e.g. r.watershed's ram, seg; i.ask, i.find, echo, lock, ...
i.oif/, r.in.wms/ are interesting as they contain platform independent
bash scripts.

Hamish

Francesco P. Lovergine wrote:

Also having a better management of libraries would be nice. Libtool
could be complex but not evil as having no versioned libraries at all.
AFAIK there is not anything that can be defined a 'grass library'
with a stable versioned API.

this post from a week ago may be of interest:
  http://article.gmane.org/gmane.comp.gis.grass.devel/16481/

Hamish

On Sun, Nov 12, 2006 at 09:15:01PM +1300, Hamish wrote:

how about one of these:

$GISBASE/share/$MODULE_NAME/binary.app

$GISBASE/support/$MODULE_NAME/binary.app

$GISBASE/bin/support/$MODULE_NAME/binary.app

$GISBASE/etc/support/$MODULE_NAME/binary.app

$GISBASE/etc/bin/$MODULE_NAME/binary.app

?

e.g. r.watershed's ram, seg; i.ask, i.find, echo, lock, ...
i.oif/, r.in.wms/ are interesting as they contain platform independent
bash scripts.

Uhm rather confused, isn't it? I think all modules requires only

configuration data -> $GISBASE/etc/$MODULE_NAME
shared libs -> $GISBASE/lib/$MODULE_NAME
scripts -> $GISBASE/share/bin/scripts/$MODULE_NAME
arch-dep programs -> $GISBASE/bin/$MODULE_NAME/
arch-indep data -> $GISBASE/share/data/$MODULE_NAME
arch-dep data -> $GISBASE/var/data/$MODULE_NAME (maybe, not sure)

and so on. They could eventually and easily be remapped for FHS.

--
Francesco P. Lovergine

Hamish wrote:
>
> how about one of these:
> $GISBASE/share/$MODULE_NAME/binary.app
> $GISBASE/support/$MODULE_NAME/binary.app
> $GISBASE/bin/support/$MODULE_NAME/binary.app
> $GISBASE/etc/support/$MODULE_NAME/binary.app
> $GISBASE/etc/bin/$MODULE_NAME/binary.app
> ?
> e.g. r.watershed's ram, seg; i.ask, i.find, echo, lock, ...
> i.oif/, r.in.wms/ are interesting as they contain platform
> independent bash scripts.

Francesco P. Lovergine wrote:

Uhm rather confused, isn't it? I think all modules requires only

configuration data -> $GISBASE/etc/$MODULE_NAME
shared libs -> $GISBASE/lib/$MODULE_NAME
scripts -> $GISBASE/share/bin/scripts/$MODULE_NAME
arch-dep programs -> $GISBASE/bin/$MODULE_NAME/
arch-indep data -> $GISBASE/share/data/$MODULE_NAME
arch-dep data -> $GISBASE/var/data/$MODULE_NAME (maybe, not sure)

and so on. They could eventually and easily be remapped for FHS.

I am not very clear on early UNIX history, but it seems that GRASS is
using "etc/" for real "et cetera", not the unix "configuration data"
meaning. Certainly all the stuff in $GISBASE/etc/ is miscellaneous "et
cetera", so our naming problem is if we should rename the dir to respect
the (slightly bizzare) unix naming convention.
(I fully support cleaning up $GISBASE/etc/, but what to name it?)

do the debian (LSB, etc) regulations state that there can be no other
"etc/" besides the unix "etc/"?

Hamish

On Sun, 12 Nov 2006, Hamish wrote:

Francesco P. Lovergine wrote:

Also having a better management of libraries would be nice. Libtool
could be complex but not evil as having no versioned libraries at all.
AFAIK there is not anything that can be defined a 'grass library'
with a stable versioned API.

this post from a week ago may be of interest:
http://article.gmane.org/gmane.comp.gis.grass.devel/16481/

Aha - so perhaps Markus or whoever added the version numbering into the library names did it because of Debian? I still don't think it's necessary because if a user has more than one GRASS version installed at once they are put in different directories.

IIUC is it true that the reason for making this fuss over version numbering and file locations is that Debian wants to install GRASS files in various places distributed across the system filesystem, rather than all one place? This is not a design assumption that has been made and would be a rather huge and pointless job to fix anyway - almost every part of GRASS assumes there is a $GISBASE directory under which the whole system is contained.

That's not to say it doesn't comply with a convention: the GRASS installation directory is (as I understand it) like a /opt-style directory, an add-on software package that includes its whole system under there, and the system-specific startup script (which really just contains the path to the GRASS installation directory) goes in /usr/local/bin. Neat and tidy. And different GRASS versions can be installed in different directories and have different startup scritps. I really think that is quite a simple and convenient solution the way it is? Well as Hamish says some things could be tidied, but not worth changing it just for the sake of it I think.

Paul

Hamish wrote:

> Uhm rather confused, isn't it? I think all modules requires only
>
> configuration data -> $GISBASE/etc/$MODULE_NAME
> shared libs -> $GISBASE/lib/$MODULE_NAME
> scripts -> $GISBASE/share/bin/scripts/$MODULE_NAME
> arch-dep programs -> $GISBASE/bin/$MODULE_NAME/
> arch-indep data -> $GISBASE/share/data/$MODULE_NAME
> arch-dep data -> $GISBASE/var/data/$MODULE_NAME (maybe, not sure)
>
> and so on. They could eventually and easily be remapped for FHS.

I am not very clear on early UNIX history, but it seems that GRASS is
using "etc/" for real "et cetera", not the unix "configuration data"
meaning. Certainly all the stuff in $GISBASE/etc/ is miscellaneous "et
cetera", so our naming problem is if we should rename the dir to respect
the (slightly bizzare) unix naming convention.
(I fully support cleaning up $GISBASE/etc/, but what to name it?)

Conventionally, programs which shouldn't be in the path go into
/usr/lib or /usr/lib/<package>. GNU added /usr/libexec with the
intention of leaving /usr/lib solely for libraries, but it hasn't
really caught on.

--
Glynn Clements <glynn@gclements.plus.com>