-
Notifications
You must be signed in to change notification settings - Fork 2
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
Split packages #2
Comments
Reducing the maintenance burden and incorporating checks is very nice. This seems like a very good idea. What do you think @bionade24 ? |
If we do go through with this change would you prefer we get it out before we sync the packages to the AUR or would you be okay if we change it after. If you think this will speed up the syncing to the AUR process than that is great, but I would rather have the packages out on the AUR before performing Nonessential fixes/cleaning. Getting it out on the AUR helps users use package managers and makes testing the arch-ROS stack much easier. |
I do think that this will speed up the porting process since we have to update less PKGBUILDs, less version numbers, less checksums to update. Also, it will be less likely to oversee a package that has a new version number for noetic. The repositories containing single packages will be updated the old way and we might port them to using In addition to that, I do not know how good the transition from One-PKGBUILD-per-package to One-PKGBUILD-per-repo will work out once our packages are on the AUR. |
I see, I still think that porting will be slower, because right now all we have to do is change melodic to noetic and sync. Boom we are on the AUR. Before moving on with this approach let us wait for @bionade24 's response.
The process is the exact same as for both cases, when you push a pkgbase to the AUR, it will also push the respective packages. |
Since a lot packages release extra versions for noetic, this is not true. (seen often: melodic: 1.14.x, noetic: 1.15.x) We might |
Yes, my original plan was to just update the packages once they are already out on the AUR, so they are easier to work with. |
You could use the update command out of my toolchain https://github.com/bionade24/aur-ci (I know name ist unfitting and I also refactored a lot of the shit but haven't merged it yet), change the settings to melodic and it should update the PKGBUILD if noetic has a newer version. |
Or wait I'll merge and push soon the you can configure the gh organization and the ROS version in a *.ini file |
Yep after going through the syncing process and updating some packages, I find this idea much more appealing. I'll let you take the lead on this @stertingen While we can use bionade24's solution for now, I think what stertigen has proposed is a cleaner solution overall. Not necessary but it is nice and if it doesn't break anything feel free to merge your changes in, @stertingen |
Sorry for forgetting this, I've merged and pushed now what I changed in between. I also like @stertingen 's idea because it's more the Arch way , but didn't want to change this when I overtook melodic. Sorry if that we uploaded that mess, somehow I had some problems with deletion via the API, but maybe it just bc PyGithub isn't maintained well and it's better to use the JSON API directly. Or I just was too dumb to set the API token rights correctly, even though I enabled nearly everything at my last try. |
no worries, it was weird that some packages were not populated, but the ones necessary for ros-noetic-desktop-full are all there now. Thx for the initial porting from melodic to noetic. |
@stertingen just want to follow up with this. I found a case where a PKGBUILD that has this structure actually causes essentially a circular dependency. See: ros-noetic-arch/ros-noetic-panda-moveit-config#3 and ros-noetic-arch/ros-noetic-franka-ros#2. Even though franka-ros does not depend on panda-moveit-config, since franka-description which is in the franka-ros PKGBUILD is a dependency of panda-moveit-config and franka-example-controller which is also in the franka-ros PKGBUILD is dependent on panda-moveit-config, it causes a circ dep, where I can't Do you have any ideas on how to work around this? |
I see two possible ways to handle this: 1. Split upI would split the set of packages into multiple This is the more elegant approach, having the feature split packages as a performance opt-in when appropriate and falling back to one PKGBUILD per package when needed. I would somehow ensure that only the relevant packages are built during 2. UnifyThrow all packages (franka-ros and panda-moveit-config) into the build tree and let the build system (catkin) sort the dependencies out. This is more the sledgehammer approach, but might be faster when building all packages together. This might not be as bad as it sounds because it seems to me like you want all of these packages installed anyway. NotesIMHO this is a design flaw that should be reported and fixed upstream, either by splitting or unifying the repositories. Apparently,
|
I made a version of the ros-noetic-roscpp-core packages as
split packages instead of multiple PKGBUILDs for each package. You can
see it here: https://github.com/ros-noetic-arch/ros-noetic-roscpp-core/blob/split-packages/PKGBUILD
This concrete PKGBUILD creates five packages, doing the same for the ros
(https://github.com/ros/ros) and ros_comm
(https://github.com/ros/ros_comm) repository would reduce the
maintenance effort for updating significantly.
On the downside, the new PKGBUILD does not rely on cmake only, instead,
I use catkin_make_isolated to build the packages in the right order.
(Since all ROS packages depend on catkin anyway, I do not mind.)
As a bonus, the PKGBUILD runs the catkin test suite to verify the build
in the check() function, but to save time, we could leave that out.
Please let me hear your opinions on migrating repositories with multiple
packages to split packages to reduce maintenance effort. I'd like to discuss whether and how we could introduce PKGBUILDs for split packages how a template PKGBUILD would look like.
The text was updated successfully, but these errors were encountered: