[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 :)

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



Reply to: