Re: [DebianGIS] build-indep for grass and other issues.
On Fri, Nov 10, 2006 at 02:44:13PM +1300, Hamish wrote:
> 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. ?
>
Yep.
> > 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?
>
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.
>
> > 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.
>
>
Yep, I proposed that as a trunk not branch thing :)
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.
--
Francesco P. Lovergine
Reply to: