I shift the discussion from github issue here to discourse, as we have to discuss something longer and more fundamental about strategy and support, as about experiences from ROS1 packaging. Currently, ROS2 gets build entirely from source, ROS1 uses my personal Server and this larger python script to maintain, test & update the packages. Since I’d overtaken the packages, we had a lot of issues, but now finally we’ re getting to a more flawless experience. Here I want to sum up ideas and options we have, and add my experiences from packaging melodic.
One upstream or distro related packages?
First decision is if we should switch to one upstream or create distro-specific packages as we do now. On the one hand the first will decrease the effort enormously, on the other hand it would be problematic for a lot of people expecting their package updates to be reliable. And telling them to do
git resetfor every package if the want the previous, probably LTS-distro is IMHO not nice
How do we want to test and build packages?
At the moment I use my private server with all the obstacles it brings along. I can’t give the build containers that much cores as need to be fast, so everything is slow as hell. Additionally, my python script is not very nice, even though I plan to improve it in various ways, e. g. creating a web UI to view build output, so that it is working a bit better for everyone. But for ROS2 I wouldn’t reinvent the wheel, so maybe choose some existing CI system. But every free CI is slower as my own server, even the new github CI has timeouts often and that doesn’t work for >400 packages after a boost update. Options would afaik be drone, jenkins & Gitlab CI, I only use the latest one, no experience with the others. But then we still need to find someone to sponsor a powerful server with at least 6 Core and 16GB RAM.
How do we organize the package structure?
Currently, we have an github organization containing every package, and then CI syncs successfully built packages to AUR. But this organization was a bad idea, probably one Repo with all would fit better, IMHO best solution would be a Repo containing submodules. But then we have the problem of testing packages before uploading to AUR again. And no,
aurpublishis a nice to, but not solving this problem. We have to build packages before syncing them, otherwise we would need to increase the
pkgrelto insanity and we would have conflicts with the AUR hooks all the time. And people would try to install/build borked updates.