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