[Home]Emc2PackagesRedesign

LinuxCNCKnowledgeBase | RecentChanges | PageIndex | Preferences | LinuxCNC.org

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)


LinuxCNCKnowledgeBase | RecentChanges | PageIndex | Preferences | LinuxCNC.org
This page is read-only. Follow the BasicSteps to edit pages. | View other revisions
Last edited October 29, 2008 7:29 am by JeffEpler (diff)
Search:
Published under a Creative Commons License