These ideas were primarily made with autopackage (ie Linux) in mind; however, as far as possible the packaging for all platforms should follow the same structure (like Windows, perhaps with MSI).

Think of the "packages" below as those that would be provided directly by or for integration into an "installer". A "source" package was intentionally excluded, on the grounds as it may not so much need an installer but rather be pulled from SVN or be a simple ZIP archive. (Arguably, the "development" packages could be delivered as such as well.)

• Utilize shared libraries
• Have the following packages:
  • crystalspace - the "runtime", ie plugins and libcrystalspace
  • crystalspace-nonfree - plugins in CS depending on non-free packages (like nvidia-toolkit)
  • crystalspace-python - python stuff in CS
  • crystalspace-java - java stuff in CS
  • crystalspace-perl - perl stuff in CS
  • crystalspace-data - runtime-relevant stuff(shaders, config, fonts, stock textures) from the data/ directory
  • crystalspace-demos - demos that show off CS, e.g. startme, walktest+maps, ...
  • crystalspace-sdk - additional developing-relevant things like headers, docs, tools, possible less flashy demo data.
  • crystalspace-debugsyms - debugging symbols - for developers as well as troubleshooting.
• Utilize autopackage's dependency support - e.g. have crystalspace depend on crystalspace-data

CEL could packaged with a similar layout.

(The idea behind having a crystalspace-data package was that developers who want to make static binaries could employ this to pull the CS data. However, perhaps we should rather promote shared libs & plugins usage - in this case, it's probably more sensible to have the data contained in the main crystalspace package.)

Shipping Targets

The main question is wether to ship CS in one directory or as installed version. This also raised the question which group we should have in mind as users of the packages: Some ideas:

Endusers:

• would probably want shared libraries installed on their system, ready for use without further interference
  • this would require packages for some major distributions and games actually willing to use that feature
  • $CRYSTAL and $LD_LIBRARY_PATH have to be adjustet by the packages itself

Developers:

• need a SDK package, including development headers and cs-config
• probably prefer cs in one directory by setting $CRYSTAL only

File Categories

(Lirrec: all files required to be shipped in packages should be assigned to the various sub-packages, this is the preliminary layout i used for my first try on opensuse-packages, which install the developer/non-installed version to "/opt/crystalspace". It would benefit all packagers on different distributions if the packages itself could have a unified file layout. The files are listed as seen from a CS-checkout directory)

• crystalspace

Base runtime, libcrystalspace*, plugin *.so files, misc

LICENSE
README
/etc/ld.so.conf.d/crystalspace.conf -- optional if a global $LD_LIBRARY_PATH modification is required
*.so - plugin libs
libcrystalspace*.so
scripts/ -- scripting bindings? (incomplete, reqires some more files from the compilation output)

• crystalspace-util

Tools, converters etc + data

Tools:

basemapgen collada2cs csbench cseditor
csfgen csimagetool cslodgen cslodview
csmocapviewer distfieldgen docconv genmeshify
heightmapgen heightmapproc levtool lighter2
maya2spr md32spr mdl2spr optimisedata partconv
shagnetron vsh walktest

Tests:

asndtest avatartest csterrainedtest eventtest
g2dtest imptest jobtest joytest
lghtngtest simdtest sndtest threadtest
tri3dtest wxtest

Data/*test
Data/editor

• crystalspace-data

Runtime required Datafiles

vfs.cfg

data/cegui
data/posteffects
data/README.data
data/renderlayers
data/shader
data/shader-old
data/shader-snippets
data/terrain
data/varia
data/viewmesh
data/config-*
data/ttf-dejavu.zip
data/unifont.zip
data/standard.zip
data/shadermgr-defaults.zip
data/fancycon.zip

• crystalspace-demos demo applications, examples and their data, remaining stuff from data/

Demos:

csisland mazing pathtut phystut
pysimp shadertut simpcd simple1
simple2 simplept simpmap transparentwindow
waterdemo waterdemo2

data/cornell
data/cube
data/deferreddemo
data/flarge
data/frankie
data/island
data/isomap
data/jane
data/krystal
data/particles
data/partsys
data/simplelights
data/simpvs
data/sintel
data/space
data/startme
data/terraina
data/terrained
data/terrainf
data/terraini
data/tests
data/water

data/bias
data/castle*

data/kwartz.zip
data/seymour.zip
data/sparka.dds
data/spark.png
data/startme.zip
data/teapot.zip
data/terrainpnp.zip
data/water.zip

• crystalspace-devel, include files, devel stuff

  cs-config
  include/*
   -- TODO: manual and api documentation
  

• crystalspace-dbg

  *.dbg
  

Debian packages

In comparison, here is the Debian package list for CS-1.4:  http://packages.debian.org/source/sid/crystalspace

There is also a separate package with dependency on nvidia-toolkit (therefore not available on the same Debian repository for licensing issues):  http://packages.debian.org/source/sid/crystalspace-glshader-cg