[Rock-dev] Github migration

Discussion:

[Rock-dev] Github migration - almost there

Sylvain Joyeux

2014-07-03 13:05:21 UTC

I've synchronized the package sets on github with the latest changes from
gitorious. I am removing commit rights on the gitorious package sets to
avoid having to re-update.

I will do a last update for the master branches of the packages (to
synchronize github). Any new commit pushed right now will have to be
re-pushed by someone else than me.

Sylvain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140703/de1157bf/attachment.htm

Matthias Goldhoorn

2014-07-03 14:48:06 UTC

Permalink

Shouldn't we simply remove also push-rights to all packages you are
already moved?

Additionally regarding the old package sets.
To prevent that everybody has to update his/her manifests know, we could
push the github version of the package sets to gitorious.

So the migration would be more smooth to our customers...

Best,
Matthias

Post by Sylvain Joyeux
I've synchronized the package sets on github with the latest changes
from gitorious. I am removing commit rights on the gitorious package
sets to avoid having to re-update.
I will do a last update for the master branches of the packages (to
synchronize github). Any new commit pushed right now will have to be
re-pushed by someone else than me.
Sylvain
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev

--
Dipl.-Inf. Matthias Goldhoorn
Space and Underwater Robotic

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-4193
Empfang: +49 421 178 45-6600
Fax: +49 421 178 45-4150
E-Mail: matthias.goldhoorn at informatik.uni-bremen.de

Weitere Informationen: http://www.informatik.uni-bremen.de/robotik

-------------- n?chster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140703/a4a8e52f/attachment.htm

Sylvain Joyeux

2014-07-03 18:26:46 UTC

Permalink

Post by Matthias Goldhoorn
So the migration would be more smooth to our customers...

Nobody's paying me, so I don't have customers. I do have users though.

And yes, I am finishing up a smooth upgrade path for them. The current
package sets will auto-import the new ones and issue a warning that the
package_sets section of the manifest should be updated.

Sylvain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140703/113e9a7f/attachment.htm

Steffen Planthaber

2014-07-04 07:42:49 UTC

Permalink

Hi,

Post by Sylvain Joyeux
And yes, I am finishing up a smooth upgrade path for them. The current
package sets will auto-import the new ones and issue a warning that the
package_sets section of the manifest should be updated.

It seems like there is a problem if the github url is not set in the
init.rb of the buildconf.

Is it possible to add it to rock.core's init.rb on gitorious to make the
smooth transition working?

in
/home/planthaber/dfki/rock/virgo/.remotes/git_git___gitorious_org_rock_toolchain_package_set_git/source.yml:
the source specification {:github=>"rock-core/package_set"} misses
either the VCS type or an URL

Steffen

Post by Sylvain Joyeux
Sylvain
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev

--
Steffen Planthaber
Weltraumrobotik

Besuchsadresse der Nebengesch?ftstelle:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Stra?e 5
28359 Bremen, Germany

Postadresse der Hauptgesch?ftsstelle Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Stra?e 1
28359 Bremen, Germany

Tel.: +49 421 178 45-4125
Zentrale: +49 421 178 45-0
Fax: +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen)
E-Mail: Steffen.Planthaber at dfki.de

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Stra?e 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------

Steffen Planthaber

2014-07-04 07:50:10 UTC

Permalink

Hi,

Post by Steffen Planthaber
It seems like there is a problem if the github url is not set in the
init.rb of the buildconf.
Is it possible to add it to rock.core's init.rb on gitorious to make the
smooth transition working?

The sections are in fact already there (found them while trying to fix
it myself).

Smooth transition is only working with "autoproj update" and NOT with "aup"

Post by Steffen Planthaber
Steffen

Steffen
--
Steffen Planthaber
Weltraumrobotik

Besuchsadresse der Nebengesch?ftstelle:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Stra?e 5
28359 Bremen, Germany

Postadresse der Hauptgesch?ftsstelle Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Stra?e 1
28359 Bremen, Germany

Tel.: +49 421 178 45-4125
Zentrale: +49 421 178 45-0
Fax: +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen)
E-Mail: Steffen.Planthaber at dfki.de

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Stra?e 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------

Sylvain Joyeux

2014-07-04 07:59:45 UTC

Permalink

Ayeee. Yes, you need to update autoproj.

Post by Steffen Planthaber
Hi,

The sections are in fact already there (found them while trying to fix
it myself).
Smooth transition is only working with "autoproj update" and NOT with "aup"

Post by Steffen Planthaber
Steffen

Steffen
--
Steffen Planthaber
Weltraumrobotik
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Stra?e 5
28359 Bremen, Germany
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Stra?e 1
28359 Bremen, Germany
Tel.: +49 421 178 45-4125
Zentrale: +49 421 178 45-0
Fax: +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen)
E-Mail: Steffen.Planthaber at dfki.de
Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Stra?e 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140704/e9911ec5/attachment.htm

Sylvain Joyeux

2014-07-04 08:05:51 UTC

Permalink

I've created to PRs (one on each package set) to make sure the user gets
the error that autoproj needs to be updated. Can someone review those
before I merge them ?

https://github.com/rock-core/rock-package_set/pull/1
https://github.com/rock-core/package_set/pull/2

Post by Sylvain Joyeux
Ayeee. Yes, you need to update autoproj.
Hi,

Post by Steffen Planthaber

The sections are in fact already there (found them while trying to fix
it myself).
Smooth transition is only working with "autoproj update" and NOT with "aup"

Post by Steffen Planthaber
Steffen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140704/75775c82/attachment.htm

Steffen Planthaber

2014-07-04 08:37:57 UTC

Permalink

Hi,

Post by Sylvain Joyeux
I've created to PRs (one on each package set) to make sure the user gets
the error that autoproj needs to be updated. Can someone review those
before I merge them ?
https://github.com/rock-core/rock-package_set/pull/1
https://github.com/rock-core/package_set/pull/2

Shouldn't those go to gitorious?

I added the version to my local rock.toolchain, rock.base and rock
package_sets, but without success.

planthaber at planthaber-u:~/dfki/rock/minirock$ aup
[...]
/git_git___gitorious_org_rock_toolchain_package_set_git/source.yml: the
source specification {:github=>"rock-core/package_set"} misses either
the VCS type or an URL

Are the remotes evaluated before autoproj is updated?

Nevertheless the patches work for my project repo which I already moved
to github.

Steffen

Post by Sylvain Joyeux
2014-07-04 9:59 GMT+02:00 Sylvain Joyeux <bir.sylvain at gmail.com
Ayeee. Yes, you need to update autoproj.
2014-07-04 9:50 GMT+02:00 Steffen Planthaber
Hi,

Post by Steffen Planthaber
It seems like there is a problem if the github url is not set

in the

Post by Steffen Planthaber
init.rb of the buildconf.
Is it possible to add it to rock.core's init.rb on gitorious

to make the

Post by Steffen Planthaber
smooth transition working?

The sections are in fact already there (found them while trying to fix
it myself).
Smooth transition is only working with "autoproj update" and NOT with "aup"

Post by Steffen Planthaber
Steffen

Steffen
--
Steffen Planthaber
Weltraumrobotik
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Stra?e 5
28359 Bremen, Germany
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Stra?e 1
28359 Bremen, Germany
Tel.: +49 421 178 45-4125 <tel:%2B49%20421%20178%2045-4125>
Zentrale: +49 421 178 45-0 <tel:%2B49%20421%20178%2045-0>
Fax: +49 421 178 45-4150 <tel:%2B49%20421%20178%2045-4150>
(Faxe bitte namentlich kennzeichnen)
E-Mail: Steffen.Planthaber at dfki.de
<mailto:Steffen.Planthaber at dfki.de>
Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Stra?e 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de <mailto:Rock-dev at dfki.de>
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev

Sylvain Joyeux

2014-07-04 09:04:23 UTC

Permalink

Post by Steffen Planthaber
Shouldn't those go to gitorious?

Yes, they should. That's why I like having people review things ...

I added the version to my local rock.toolchain, rock.base and rock

Post by Steffen Planthaber
package_sets, but without success.

This is correct. Autoproj checks the version *after* the package set
import. There's really no way out of this problem. Let's hope that most
people run autoproj update or aup --all when they update their systems.

Sucks ...

Anyways, I've created a patch so that aup /in the root of the autoproj
installation/ is equivalent to autoproj update. Cannot fix our problem,
unfortunately :(
https://github.com/rock-core/autoproj/pull/13

Sylvain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140704/42970842/attachment.htm

Matthias Goldhoorn

2014-07-04 07:29:15 UTC

Permalink

I changed my first packages to the new ones.

Unfortunately i ran into a problem. Before i had in the layout section
of my manifest something like

- rock.toolchain
this builds me all core-stuff of rock, but not the gui-related packages.
(i don???t want to have vizkit e.g. on my roboter).
Now i added
- rock.core
to the layout but i cannot exclude vizkit anymore since the package does
not allow weak dependencies.

So what's the best way to solve this?

Best,
Matthias

Post by Matthias Goldhoorn
So the migration would be more smooth to our customers...
Nobody's paying me, so I don't have customers. I do have users though.
And yes, I am finishing up a smooth upgrade path for them. The current
package sets will auto-import the new ones and issue a warning that
the package_sets section of the manifest should be updated.
Sylvain

--
Dipl.-Inf. Matthias Goldhoorn
Space and Underwater Robotic

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-4193
Empfang: +49 421 178 45-6600
Fax: +49 421 178 45-4150
E-Mail: matthias.goldhoorn at informatik.uni-bremen.de

Weitere Informationen: http://www.informatik.uni-bremen.de/robotik

-------------- n?chster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140704/3a82933a/attachment.htm

Sylvain Joyeux

2014-07-04 07:31:54 UTC

Permalink

On Fri, Jul 4, 2014 at 9:29 AM, Matthias Goldhoorn <
I will only migrate the core packages (what I have done so far). The rest
of the packages should be migrated by their respective maintainers when
they feel like it.

Sylvai
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140704/0b67a0ed/attachment.htm

Sylvain Joyeux

2014-07-04 07:32:50 UTC

Permalink

On Fri, Jul 4, 2014 at 9:29 AM, Matthias Goldhoorn <

Post by Matthias Goldhoorn
So what's the best way to solve this?

Create a rock.core.nogui metapackage. Make it a duplicate of the rock.core
metapackage, but without the GUI packages.

Sylvain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140704/caf0cea5/attachment-0001.htm

Christian Rauch

2014-07-08 11:27:03 UTC

Permalink

Hi,

I am hitting the same problem about the gui dependency in rock.core now

Post by Sylvain Joyeux
On Fri, Jul 4, 2014 at 9:29 AM, Matthias Goldhoorn <

Post by Matthias Goldhoorn
So what's the best way to solve this?

Create a rock.core.nogui metapackage. Make it a duplicate of the rock.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

Post by Sylvain Joyeux
Sylvain
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de
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: Christian.Rauch at dfki.de

Weitere Informationen: http://www.informatik.uni-bremen.de/robotik

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5071 bytes
Desc: S/MIME Cryptographic Signature
Url : http://www.dfki.de/pipermail/rock-dev/attachments/20140708/ba8c2034/attachment.bin

Sylvain Joyeux

2014-07-08 11:53:13 UTC

Permalink

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.

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.

Sylvain

On Tue, Jul 8, 2014 at 1:27 PM, Christian Rauch <Christian.Rauch at dfki.de>

Post by Christian Rauch
Hi,
I am hitting the same problem about the gui dependency in rock.core now
On Fri, Jul 4, 2014 at 9:29 AM, Matthias Goldhoorn <

Post by Matthias Goldhoorn
So what's the best way to solve this?

Post by Sylvain Joyeux
Create a rock.core.nogui metapackage. Make it a duplicate of the

rock.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

Post by Matthias Goldhoorn
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de
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
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: Christian.Rauch at dfki.de
Weitere Informationen: http://www.informatik.uni-bremen.de/robotik
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140708/e57b9c0f/attachment.htm

Martin Zenzes

2014-07-08 11:57:59 UTC

Permalink

the embedded guys don't want to have anything to do with gui-stuff. In
my view: keep the minimal depedency-chain as short as possible.
otherwise people will start talking using words like "bloated"

Post by Sylvain Joyeux
Moreover, rock.simulation is not part of rock.core, and should IMO not be.
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.

so no gui-dependency in central packages?

Post by Sylvain Joyeux
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?

+1

martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140708/d9980efa/attachment.htm

Sylvain Joyeux

2014-07-08 12:10:30 UTC

Permalink

Post by Sylvain Joyeux
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.
the embedded guys don't want to have anything to do with gui-stuff. In my
view: keep the minimal depedency-chain as short as possible. otherwise
people will start talking using words like "bloated"

Sorry if I hurt your feelings, but the embedded guys are far from being the
"common case". Moreover, if you want to reduce the number of packages you
install on your embedded system to a minimum (which is probably what you
want), then having a metapackage is not what you are looking for. You want
to pick packages one by one.

Now, as a middle ground, where would a rock.core.nogui metapackage not fit
the "embedded guy" case ?

Sylvain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140708/62c90178/attachment-0001.htm

Christian Rauch

2014-07-08 12:41:51 UTC

Permalink

Post by Sylvain Joyeux

Sorry if I hurt your feelings, but the embedded guys are far from being the
"common case". Moreover, if you want to reduce the number of packages you
install on your embedded system to a minimum (which is probably what you
want), then having a metapackage is not what you are looking for. You want
to pick packages one by one.
Now, as a middle ground, where would a rock.core.nogui metapackage not fit
the "embedded guy" case ?

Does this imply that two metapackages (rock.core + rock.core.nogui) need
to be maintained simultaneously? So, once changes are pushed in one of
the metapackages, they also need to be applied to the other metapackage.

What are the arguments against the rock.core.gui package that depends on
rock.core?

Regards,
Christian

Post by Sylvain Joyeux
Sylvain
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev

Martin Zenzes

2014-07-08 12:19:53 UTC

Permalink

On Tue, Jul 8, 2014 at 1:57 PM, Martin Zenzes <martin.zenzes at dfki.de

the embedded guys don't want to have anything to do with
gui-stuff. In my view: keep the minimal depedency-chain as short
as possible. otherwise people will start talking using words like
"bloated"
Sorry if I hurt your feelings, but the embedded guys are far from
being the "common case". Moreover, if you want to reduce the number of
packages you install on your embedded system to a minimum (which is
probably what you want), then having a metapackage is not what you are
looking for. You want to pick packages one by one.

i'm not directly talking about the "autoproj metapackage", but the
underlying assumption that people *want* the gui. people are not the
only entities using the software. think about automated testing, for
example. headless robots are another case.

Now, as a middle ground, where would a rock.core.nogui metapackage not
fit the "embedded guy" case ?

in the way that "rock.core" itself implies (in my view) the "nogui"
part. "rock.core.gui" makes more sense.

none of my feelings are hurt just posted my opinion ;-)
--
M.Sc. Martin Zenzes
Space Robotics

Hauptgesch?ftsstelle Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Stra?e 5
28359 Bremen, Germany

Phone: +49 (0) 421 178 45 - 6658
Fax: +49 (0) 421 178 45 - 4150
E-Mail: martin.zenzes at dfki.de

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Stra?e 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140708/6c23e08d/attachment.htm

Christian Rauch

2014-07-08 12:26:06 UTC

Permalink

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.

Post by Sylvain Joyeux
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.

Post by Sylvain Joyeux
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.

I agree here. If one selects rock.core, all drivers (even unused) will
be installed.

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

Post by Sylvain Joyeux
Sylvain
On Tue, Jul 8, 2014 at 1:27 PM, Christian Rauch <Christian.Rauch at dfki.de>

Post by Christian Rauch
Hi,
I am hitting the same problem about the gui dependency in rock.core now
On Fri, Jul 4, 2014 at 9:29 AM, Matthias Goldhoorn <

Post by Matthias Goldhoorn
So what's the best way to solve this?

Post by Sylvain Joyeux
Create a rock.core.nogui metapackage. Make it a duplicate of the

rock.core
metapackage, but without the GUI packages.
Wouldn't it be better to have it the other way around?

Post by Matthias Goldhoorn
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev

_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev

Jakob Schwendner

2014-07-08 12:40:53 UTC

Permalink

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.

In my opinion this is what we have a dependency system for. There is no such
thing as stuff that everyone needs. You select the things you want, e.g.
imu_driver, motion_controller, and it will select the required dependencies
for you. You can then even add or not add the gui package, and since the
optional feature will use this information to compile in or not compile the
vizkit stuff.

I don't see package-sets as things that get compiled as a whole other than
for testing.

Cheers,

Jakob

Sylvain Joyeux

2014-07-08 12:42:07 UTC

Permalink

On Tue, Jul 8, 2014 at 2:26 PM, Christian Rauch <Christian.Rauch at dfki.de>

Post by Sylvain Joyeux
I don't like this, as in most situations people *want* the GUI. The nogui

Post by Sylvain Joyeux
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.

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.

All (or close) of developers installations will most probably want the GUI.
All control stations will want the GUI. The only

With rock.core as it is right now, we basically cover 90% of all the rock
installations. That's the very goal of having a rock.core in the first
place, as it is part of the rock core "experience" (I hate that word ...).

Post by Sylvain Joyeux
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.

Why not ? You can run components without orocos.rb. Probably something that
will happen more and more in embedded systems, where one will just start a
deployment with the few relevant components inside, doing the
"orchestration" from another machine. No roby, no syskit, no ruby for that
matter. You could even pre-generate the components on a separate machine
and only build them on the target machine (that would remove orogen). As
soon as we start speaking about particular needs, I really don't see where
the limit is.

The problem with this whole thread is that you are opening a can of worms.
I want, with the rock.core metapackage, to cover 90% of the installations
*and* make it easy for new users.

By just using the minimal packageset I don't need to select all required

Post by Sylvain Joyeux
packages manually and you are not forced to install optional packages.

FYI, the only way to get rid of an optional package is currently to exclude
it from the build.

Sylvain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140708/3d91cc03/attachment.htm

Matthias Goldhoorn

2014-07-08 13:07:25 UTC

Permalink

I also don't want to maintain a additional package, that's the reason
why i decided against the creation.
I liked the setup with two different packages <core> and <gui> too. But
it seems not wished to keep this separated anymore.

------ but

I solved this (for me) by doing:

in overrides.rb:
if Autoproj::Metapackage.method_defined?(:weak_dependencies?)
metapackage('rock.core').weak_dependencies = true
end

in manifest.xml:
exclude_packages:
- ocl
- gui/vizkit
- gui/vizkit3d
- gui/rock_widget_collection
- simulation/.*

maybe we can add to the rock-core a function like
"remove_gui_packages"

which set's the weak dependencies and ignore for all...

thoughts?

Matthias
--
Dipl.-Inf. Matthias Goldhoorn
Space and Underwater Robotic

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-4193
Empfang: +49 421 178 45-6600
Fax: +49 421 178 45-4150
E-Mail: matthias.goldhoorn at informatik.uni-bremen.de

Weitere Informationen: http://www.informatik.uni-bremen.de/robotik