gnucash files for SuSE 8.1 on sf

Greg Troxel gdt at ir.bbn.com
Sun Feb 16 12:23:14 CST 2003


  Also, we should make a requirement that donated packages conform to the 
  File-system Hierarchy Standard (http://www.pathname.com/fhs/ or
  http://www.linuxman.com.cy/rute/node38.html).  This shouldn't be an

Please also remember that the world is more than GNU/Linux systems.  I
am using NetBSD and FreeBSD, for example.  I'm not in any way opposed
to people providing binary packages for many kinds of GNU/Linux
systems, but I wanted to point out that distribution issues go beyond
this.  In *BSD, packaging involves maintaining an entry in /usr/ports
or /usr/pkgsrc, from which the program can be compiled and binary
packages made.  Particularly in NetBSD, the focus is on correct and
clean pkgsrc control files rather than binaries, since there are so
many different architectures.  The transition from guile 1.4 to 1.6
has made this difficult, although I now realize that gnucash 1.8 can
work with either.  And, NetBSD pkgsrc now supports simultaneously
installing guile 1.4 and 1.6:

  > /usr/pkg/bin/guile --version
  Guile 1.6.1
  > /usr/pkg/guile/1.4/bin/guile --version
  Guile 1.4.1

I'm hoping to update the NetBSD pkgsrc for g-wrap and gnucash when I
find some spare time.  Because other programs don't link to gnucash,
there should be no need to support having gnucash 1.6as well.

Nothing much more than what exists now needs to be done to ease
packaging for BSD systems: the two big things are portable code that
relies on POSIX, and has portability mechanisms to deal with non-POSIX
behavior, and the ./configure --prefix ability to put the resulting
system in a different place (NetBSD uses /usr/pkg).  I posted about a
few bugs in 1.7.8, but they were easy to fix (lack of const
correctness) and not very numerous.

A larger issue which might be good to contemplate is how .so files to
be dlopened get located.  Right now this seems to be a LD_LIBRARY_PATH
thing, and I have an aversion to searching in larger numbers of places
for things, since it loses when multiple versions are installed in
different prefixes.  As I've said on the guile list, when a program
installed with --prefix=/usr/foo wants to link a library it installed,
it can open /usr/foo/libexec/plugins/bar.so explicitly, rather than
putting /usr/foo/libexec/plugins in LD_LIBRARY_PATH and opening
bar.so.  The downside to this is running before installation, and I
don't have a good answer for how to do both.

 Greg Troxel <gdt at ir.bbn.com>


More information about the gnucash-user mailing list