Am 08.07.2014 13:53, schrieb Sylvain Joyeux:
For me the gui should be also not a part of the toolchain. The toolchain should contain tools for building and running a system. The gui is used to visualize and debugging.I don't like this, as in most situations people *want* the GUI. The nogui case is a special case. all packages including the GUI is the common case. Note that gui/vizkit was already part of rock.toolchain before the migration.
Moreover, rock.simulation is not part of rock.core, and should IMO not be.
That was just an example on how metapackages should depend on each other.
I agree here. If one selects rock.core, all drivers (even unused) will be installed.Finally: in principle, one should not *have* to use rock.core on a "finalized" system (such as a robot) as he can enumerate the packages he needs instead of selecting rock.core. Since we are talking about having e.g. a robot, it would IMO be a better approach as it ensures that, on the headless system, there are only packages that are useful.
But there should be one metapackage (rock.minimal?) that only contains the packages from the infrastructure that every installation really needs, for example orogen, rtt, base-types, roby, syskit. Without them you cannot build and run any rock installation. All specific packages like drivers, image_processing and gui should be in their own optional metapackages.
By just using the minimal packageset I don't need to select all required packages manually and you are not forced to install optional packages.
Regards, Christian
Sylvain On Tue, Jul 8, 2014 at 1:27 PM, Christian Rauch <[email protected]> wrote:Hi, I am hitting the same problem about the gui dependency in rock.core now and would like to reopen that discussion again: Am 04.07.2014 09:32, schrieb Sylvain Joyeux: On Fri, Jul 4, 2014 at 9:29 AM, Matthias Goldhoorn <[email protected]> wrote: So what's the best way to solve this?Create a rock.core.nogui metapackage. Make it a duplicate of therock.core metapackage, but without the GUI packages. Wouldn't it be better to have it the other way around?There should be one metapackage containing only the necessary packages to have the robot running and have additional metapackages for gui and simulation. E.g. a package rock.core itself should not depend on gui packages, but should contain the toolchain and drivers. Two additional metapackages rock.gui and rock.simulation should depend on rock.core and add their additional packages. Suggestions? Regards, Christian Sylvain_______________________________________________ Rock-dev mailing list [email protected] http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev-- Christian Rauch Space Robotics Universität Bremen FB 3 - Mathematik und Informatik AG Robotik Robert-Hooke-Straße 1 28359 Bremen, Germany Zentrale: +49 421 178 45-6611 Besuchsadresse der Nebengeschäftstelle: Robert-Hooke-Straße 5 28359 Bremen, Germany Tel: +49 421 178 45-6619 Empfang: +49 421 178 45-6600 Fax: +49 421 178 45-4150 E-Mail: [email protected] Weitere Informationen: http://www.informatik.uni-bremen.de/robotik _______________________________________________ Rock-dev mailing list [email protected] http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev_______________________________________________ Rock-dev mailing list [email protected] http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
-- Christian Rauch Space Robotics Universität Bremen FB 3 - Mathematik und Informatik AG Robotik Robert-Hooke-Straße 1 28359 Bremen, Germany Zentrale: +49 421 178 45-6611 Besuchsadresse der Nebengeschäftstelle: Robert-Hooke-Straße 5 28359 Bremen, Germany Tel: +49 421 178 45-6619 Empfang: +49 421 178 45-6600 Fax: +49 421 178 45-4150 E-Mail: [email protected] Weitere Informationen: http://www.informatik.uni-bremen.de/robotik
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Rock-dev mailing list [email protected] http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
