On Saturday 13 September 2008, Alex Joni wrote: > describing some vague ideas around redoing the emc2 packages. > So far it's only a description of some of the things I think would be nice, > not sure they can be all implemented.
Will you be conducting a full and complete audit of the code ? > rtai-*|emc2-sim-something > basic realtime|sim package > emc2-hal > HAL only install (our HAL, not linux HAL..) Pointless split - ratpi & hal are so intertwined, it isn't worth packaging as seperate entities. > emc2-modules-<kver> > emc2 kernel modules (depends on the kver kernel image) I proposed this a couple of years ago - To make it a worthwhile exercise, you *need* to remove hard coded kernel version(s) from the usr space stuff. > emc2-base > Base emc2 Package (depends on a emc2-modules, emc2-hal) Perhaps - Really depends on what goes in. > emc2-dev > Development files - to easily add new components to emc2. (depends on > emc2-base). Perhaps - Although if headers for GUI extensions are included, the dependencies include a lot more than just "base". > emc2-gui > Different GUI's bundled (depends on emc2-base) Split the user interfaces out - You could have a seperate package for each one. > emc2 > Pseudo Package allows a complete install (depends on emc2-gui) A meta package usually depends on all except the -dev packages. > 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) How would you propose handling the case of installation of a GUI to connect toa remote non-GUI install ? > Regular users might want to build emc2 (to try TRUNK), so a minimal > build-dep is best (no > lyx, or other documentation needed). build-dep is the WRONG way to handle users - They *might* not even be running a Debian system. Fix the documentation and build system. > Documentation > getting rather large, would be best in a separate package - with separate > build-deps You mean documentation is bundled in the current package ??? Again, don't try friggin' around with build-deps, you only cause problems at a later stage. > Sim package > same repo? can it coexist with an installed emc2? maybe different > emc2-base package *IF* you got rid of hard coded kernel versions, paths, and all the other crap infecting a user environment, a -sim package *might* coexist. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
