Managing a metapackage with ROS
Hi, I have been trying to create a meta-package for a ROS repository, which is consisted of several other meta-packages, while also being able to resolve all the dependencies of the internal meta-packages. At first, I thought creating a recursive solution which involves a symbolic link inside the meta-package folder and points to different meta-packages, later on pointing to the actual packages. After playing with the idea a bit, I think it might require too much effort to work and was wondering what is the correct way to properly manage the ROS package. I will try to depict the scenario I am facing, which might help understand the issue I am facing. Package A, B , C, D, E are ROS packages, they are dependent on both custom package and apt-get resolvable packages. They reside in a src folder. Package X Y are meta packages which are consistent of the above, why the package Z depends on both X and Y.
Currently the solution is simply run rosdep install on the src folder, install all dependencies and then resolve the meta packages. This results a rather large installation which sometimes also has unnecessary dependencies installed.
I would like rosdep install --from-package=Z to be able to resolve all the dependencies properly without any extra steps.
Maybe the correct way is not to manage the meta-packages in a package.xml file as is not really meta-package oriented. Maybe a recursive solution where each meta-package points has a symbolic link pointing to the packages is worth investing more time at. I thought about creating a debian package for each one of the non-meta packages and simple creating a local repository, as debian files have dependency by nature when using rules/control files.
My experience is rather limited at the moment to see a clear apporach to the correct solution.
Thanks, Shauli
It's unclear to me what you actually want to do, but a general observation/bit of input: metapackages do not contain any code/files themselves, and are not intended to. The only files they contain are the build script, package manifest and perhaps a
LICENSEandCHANGELOGfile.Metapackages are not intended to install any files themselves, this is all taken care of by the build tooling. In fact, the build script contents is prescribed, and should not be changed.
As I don't really understand your question, I cannot give a better answer, but at least wanted to clarify that things like "perhaps I should add git submodules to my metapackage" or "symbolic links in metapackages" are not really things you should be contemplating when talking about metapackages.