Proposition for new emc2 Packages

Rationale

not optimal to stick everything into one big binary package

Ponderings

Non-GUI install

have the possibility to install a minimal working emc2, without lots of dependencies, and without X required. (this will work with remote GUI's, and maybe have keystick installed)

Regular users

might want to build emc2 (to try TRUNK), so a minimal build-dep is best (no lyx, or other documentation needed).

Documentation

getting rather large, would be best in a separate package - with separate build-deps

Sim package

same repo? can it coexist with an installed emc2? maybe different emc2-base package

Packages

Note: might be pushing into the other extreme.. too many packages. (atm only for discussion). fenn thinks this is not an unreasonable number of packages

rtai-*|emc2-sim-something

basic realtime|sim package

emc2-hal

HAL only install (our HAL, not linux HAL..)

emc2-modules-<kver>

emc2 kernel modules (depends on the kver kernel image)

emc2-base

Base emc2 Package (depends on a emc2-modules, emc2-hal)

emc2-dev

Development files - to easily add new components to emc2. (depends on emc2-base).

emc2-gui

Different GUI's bundled (depends on emc2-base)

emc2

Pseudo Package allows a complete install (depends on emc2-gui)

emc2-mesa-firmware

large device firmwares that are not required by most users

Peanut gallery

why have both emc2-base and emc-modules-<kver>? one is useless without the other.

couldnt emc2-sim substitute for emc2-base in the sim case? (and not depend on any rtai compatibility package)