On 08/16/2017 04:19 PM, Till Hofmann wrote: > Hi all, > > I'm currently working on packaging the whole ROS stack by automatically > generating SPEC files with the help of the rosinstall_generator. I think > the project is far enough to be shared on this list, but it is still > work in progress. > > The SPEC files are generated with a python script. You can check it out > here: https://pagure.io/ros > > I've created a COPR for ROS Kinetic that contains all packages from > desktop_full and move_base for F24+ (currently only for x86_64): > https://copr.fedorainfracloud.org/coprs/thofmann/ros/ > > The scripts should also work for ROS Lunar (and possibly other > releases), but I've only tested Kinetic so far. > > I decided to package each ROS package into a separate Fedora package, > because imho that's the best mapping from ROS to Fedora: Each package > has its own sources, different dependencies, and some packages require > different build arguments. This way, it's also much easier to add new > (ROS) packages to Fedora. > > I picked /usr/lib64/ros as ROS_ROOT. Currently, this does not allow > having two separate ROS installations. But moving it to e.g., > /usr/lib64/ros/kinetic should be as simple as adapting the template > file. Is that something we would want to have? > > There are still some remaining tasks on my list: > - Provides: for ros-$pkgname (currently, the packages are all called > ros-kinetic-$pkgname) > - Clean up dependencies, many packages have explicit runtime > dependencies that they don't need because they are automatic > dependencies on the sonames. Some packages also have devel packages as > runtime dependency, which is of course incorrect. > - Splitting devel packages. I'm not sure how useful this would be, but I > think it is required by the packaging guidelines. > - I thought about adding the ROS lib dir to /etc/ld.so.conf.d, but I'm > not sure whether this is a good idea because most libraries have > unversioned sonames. On the other hand, all the packages currently > Provide: their (unversioned) libraries, which may have unexpected > effects, e.g., a program linking (and requiring) a ros lib without > sourcing the ROS environment. > - As it is, the ROS packages have a lot of bundled third-party > libraries. This may require some work to separate if at all possible. > - I haven't really checked any existing Fedora ROS packages other than > catkin_pkg. Wow, thanks for taking this on. I haven't had any cycles to work on ROS in a long time, but this is work I support. * I do think that making -devel packages might be useful, but if you can make the case as to why they aren't useful (as opposed to "harder to script"), you can probably get an exception for ROS packages. * I don't think you want ROS libs in the ld cache, that seems like a recipe for disaster. You also probably want to disable the autoprovides generation and instead do something like: Provides: ros(library.so) or Provides: ros-kinetic(library.so) * The unbundling is going to suck, except in the rare cases where the bundled code is unmodified. Thankfully, you should be able to use the bundled code as long as you follow the Fedora Packaging Guidelines around that: https://fedoraproject.org/wiki/Bundled_Libraries ~tom _______________________________________________ robotics mailing list -- robotics@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to robotics-leave@xxxxxxxxxxxxxxxxxxxxxxx
