dist: add desvirt

[phiros]

This adds desvirt and a example topology to pkg dist.
Desvirt can be used in conjunction with pytermcontroller for network related tests.

[OlegHahm]

Hm, I somehow wonder if wouldn't be saner to configure the path to desvirt for pytermcontroller somewhere and not use it as package. I would expect packages to be rather modules for RIOT than tools that can use RIOT if you see what I mean. Does this make sense to you?

[LudwigKnuepfer]

I agree with @OlegHahm

[kaspar030]

Me too. Any scripts for using RIOT with des-virt should go into dist/.

[phiros]

The main reason why I put desvirt into pkg is ease of use (the path to desvirt is known to other scripts; the user doesn't have to download and configure desvirt by hand etc.).
However, I understand your reservations against misusing pkg for such purposes.
A solution to this problem which comes to mind would be to create a directory similar to pkg in dist/tools. This directory would serve the same purpose as pkg only for software tools which either can use RIOT or are of use for the development process (but cannot be integrated directly into dist/tools for license or other issue).
Would such a solution be OK for all of you?

[LudwigKnuepfer]

I don't understand what you are up to .. If des-virt is in dist/tools you know the path and could just call it directly.

[miri64]

Why don't we include des-virt in dist/tools as a git-submodule again?

[phiros]

@LudwigOrtmann Yes, for desvirt this is feasible (and I will change this PR accordingly).
However, we should IMHO really think about a pkg equivalent for dist/tools. Sooner or
later we might want to integrate a tool which is either too big in terms of disk space or problematic in terms of its license.

@authmillenon Might be a good idea. I will think about it.

[LudwigKnuepfer]

Ah, those are two different questions: a) how to add software to the repo, and b) how to invoke it. This wasn't clear to me.

Things to watch out for with submodules:

• What needs to be done to initialize?
• Can and should initialization be automated?
• How will it be updated?
• Does everyone have to update their checkout manually?

[miri64]

@LudwigOrtmann Yes, for desvirt this is feasible (and I will change this PR accordingly).
However, we should IMHO really think about a pkg equivalent for dist/tools. Sooner or
later we might want to integrate a tool which is either too big in terms of disk space or problematic in terms of its license.

There was two reason for the pkg paradigm: keep the RIOT build system as independent from the git repository structure itself as possible (so submodules where out of the question) and keeping the packages itself as independent from git as possible, while being somewhat homogeneous in there make-up (because there might be and are [take openwsn e.g.] projects that don't have a git repository and offer there source code only through other VCS or archives).

dist/tools however is more or less independent from our build system and since desvirt is more or less under our control I would vote for inclusion via git submodule. Since submodules are only pulled if the user initiates it via git submodule update [<path>] the disk space argument is not really valid. Same goes for the license argument, since these are tools that don't really belong to the code base of RIOT and are clearly marked as external due to there nature as submodule.

[OlegHahm]

Sounds valid. I would say, go ahead with the submodule solution, @phiros.

[OlegHahm]

The reason for the proposed solution is the introduction of an exemplary desvirt configuration, right? How about adding this to the desvirt repository directly and go with the submodule here?

[OlegHahm]

I think for desvirt it's safe to use master here.

[miri64]

There is still the pkg/ vs. submodule to dist/ discussion open, am I right?

[OlegHahm]

As far as I see the discussion is package in dist/ vs. submodule in dist. I would prefer the latter on, but the first one would work, too.

[phiros]

@OlegHahm The point of this PR is to provide RIOT users (and certain utilities) with a configuration for desvirt (not only a topology but also a well known path to desvirt). As we might want to provide some other topologies (using different applications) I feel it would be easier to have those in the RIOT repo instead of a sub-module.

[OlegHahm]

ACK. Please squash.