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

Problems with packaging of dstooltk (policy/libs).



Hi all,

I sent an ITA wrt to dstooltk and dstooltk-doc to wnpp. 
I'm not (yet) a Debian developer (but maybe someone is willing to sponsor
me?), but have been a user since '97 and use dstool for my
research; that's why I didn't want to have it orphaned.

There are basically two versions of dstool: the packages dstool and
dstool-doc are from the xview based version, and the tk packages tcl/tk
based. The tcl/tk based one is more modern (Jul '98 vs. Jan '96) and does
its job. I don't know of a reason to use the xview version instead of the
tk based version.

Upstream development has (hardly) not occured since jul '98: see 
www.cam.cornell.edu/guckenheimer/dstool.html

I've done a fair amount of work trying to modernise the package: using a
.orig file, and using the dh_* scripts in debian/rules.

Most problems I had trying to make a package had to do with FHS compliance
and something that is not supported in John Lapeyre's package: user
models.

In dstool(tk), a user can create a .c-file containing a few functions
defining a dynamical system (equations and such); there's no main(). This
.c file can then be linked to the dstool libraries and results in a new
executable: a user's dstool including his/her own model.

The problem is where to put the libraries and other help files. The
upstream version places all files in /usr/lib/dstooltk + subdirs, where
platform dependent files are placed in directories like
/usr/lib/dstooltk/lib/linux/ (for linux systems) or
/usr/lib/dstooltk/lib/solaris/ (for solaris systems), etc. where the .a
static libraries are placed.
While this does not specify enough (consider i386-linux vs. powerpc-linux
vs. ...), it's also not necessary following FHS since /usr/lib _is_
already assumed to be platform specific. The platform independent stuff
had to be moved to /usr/share, of course.

And this scheme is repeated for the user's dstool:
$HOME/$MYDSTOOL/linux/bin/dstooltk,
$HOME/$MYDSTOOL/solaris/bin/dstooltk, etc.
This is probably (sort of) appropriate for multi-platform NFS-shared home
directories, it's still a bit funny, since a recompile is usually
done quickly enough.

Anyway, I came up with the following (more natural to Debian) scheme:
- platform independent in /usr/share/doc/dstooltk
- 1 shared library /usr/lib/libdstooltk.so.2.0
- binary (script) is in /usr/bin/dstooltk and chooses whether to execute
the standard dstooltk binary /usr/bin/dstooltk.real or the user's version
based on the setting of an environment variable _or_ the user can just
execute the user's version directly in which case /usr/bin/dstooltk is
enough.

With a shared library, we also need a package with header files and a
static library. This would even give three packages (four including doc):
dstooltk (depends on libdstooltk)
libdstooltk
libdstooltk-dev

Seems a bit like overhead to me, but this was the best I could think of.
Does someone know of a better solution?

Regards,
Bart




Reply to: