-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
auto-discover apt sources from /etc/apt/sources.list.d/ #107
Comments
"Discovering" the repository won't actually let you resolve this dependency. Those repositories listed are the ones that are required for using the rosdistro and are expected to be already available on the target platforms, the ubiquity repository is not expected to be available on the target platform and the error that you're getting is a precursor to the bundle failing to install on the other end because the target system won't have the ubiquity repositories setup and thus won't be installable from the bundle generically. |
Doesn't colcon bundle take all the apt dependencies required and add them to the zip so they don't need to be installed from apt on the robot? Why can't the packages be used/installed from the bundle generically? Isn't that the point of bundling? The idea is that I want to be able to setup Ubiquity Robots repository on my development machine, install raspicam, then bundle and have raspicam added to that bundle so it can be used with the robot without having to install it from apt. This should at least give a more helpful error explaining to the user why they can't bundle the package they need. |
There's a significant difference between bundling content into user space and installing system dependencies. I would be quite unhappy if I used a bundle and it injected a system package onto my system that's not in my apt sources. Versus it just installing things that I've already declared trusted. Note that I believe that it only persists the apt package names and not the actual binaries. And this also means that you don't have to do things like a recursive dependency walk to install packages. For example if
I would agree with this approach if it setup a full chroot and didn't install the packages onto the system. But again this is getting towards what a container provides.
Collecting the known sources.list and displaying it when the bundle install fails might make sense to give the user the option to add an apt source. Alternatively it could also build the cache when generating the bundle and warn or error that the apt source is missing. It also appears that there is an option for you to add an apt source when installing you could use:
|
I'm using the package
raspicam_node
which comes from the ubiquity robotics apt repositoryhttps://packages.ubiquityrobotics.com/ubuntu/ubiquity
.It built and ran fine, but when running colcon bundle it failed to find the package from apt throwing the following error:
The reason for this is colcon bundle has it's own list of apt sources in /etc/apt/sources.list.d (https://github.com/colcon/colcon-bundle/blob/8eb65de65d3cdd601119528331e84849b6ecba74/colcon_bundle/installer/assets/xenial.sources.list) and this list doesn't contain the ubiquty robotics repository.
I think colcon bundle should automatically pull in any custom defined apt repositories in
/etc/apt/sources.list.d/
(or similar location on other OS's) so users aren't confused about this in the future.The text was updated successfully, but these errors were encountered: