---

date: '2008-10-29T15:29:25' title: Emc2PackagesRedesign

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)