apriltag ROS package is colliding with the system packaged version
tfoote opened this issue · comments
The ROS package has 3.3 https://index.ros.org/p/apriltag/#humble
Ubuntu as of Jammy has 3.2: https://packages.ubuntu.com/jammy/apriltag
As this is now packaged upstream we should make a migration plan to move it to the system packages instead of packaging it ourselves.
To not break anything we should remove it from rolling and forward (Iron) but keep it in humble and later.
We will need to:
- create a new rosdep key
- migrate apriltag_ros to use the rosdep key
I saw this as well, in fact our posts went up at the same time.
One thing to bear in mind is that Iron's other platforms may not have a suitable version of this dependency. A quick incomplete check suggests that apriltag isn't in EPEL 9 and the version in Debian Bullseye (stable) is quite old. Debian Bookworm (testing) has the latest version currently tagged and is due for hard freeze in March but may not be officially released until after the Iron release. All that is to say, we may need a vendor package to fill the gaps if we're going to transition Ubuntu to the upstream package.
Indeed if it's not quite ready for Iron to remove it might make sense to delay it. But if that's the case we should push on the other platforms to get coverage and plan it for after Iron.
Also this isn't a core package so could be considered for release onto Debian after the main freeze.
But either way we should work to clear it out as a dependency either this cycle or next.
Hi @tfoote,
Many thanks for flagging this up. Happy to follow your action plan and recommendations. Based on @nuclearsandwich's insights, would Rolling / Iron stick with vendored and then drop it depending on system packages thereafter? Or would it make sense to revert to 3.2 in the vendored package to make the conditional transition easier?
Based on @nuclearsandwich's insights, would Rolling / Iron stick with vendored and then drop it depending on system packages thereafter?
REP-2000 updates for Iron haven't been made yet but the ROS Infrastructure team has already started planning for our intended Iron platforms. Getting apriltag into EPEL 9 so we can use it in RHEL/AlmaLinux 9 would help lock down our Tier 2 platform. I think that Debian will 100% on whether they manage to release before we do or whether I can make a compelling case for Iron to target Bookworm even if it's still testing at the time of Iron's first release, which is a dicey proposition that I'm not even sure I'd be in favor of on most days but the timing is very unfortunate since a lot of our upstreaming efforts for Ubuntu 20.04 will also become available in Bookworm.
I think that if all the stars align
Or would it make sense to revert to 3.2 in the vendored package to make the conditional transition easier?
I think this depends entirely on the differences between 3.2 and 3.3. If there are no source changes required to depend on either version of apriltag, I think it would be fine to leave the vendored package as-is, while taking steps to rename it so that it's no longer shadowing the eventual system rosdep key.
Another fraught question is whether we really want to "downgrade" apriltag in Iron to 3.2. I'm assuming that there are bug fixes and improvements which would be rough to lose for people transitioning from Humble to Iron. I wonder if we make this change in Rolling but patch the vendor package in Iron to vendor if the target platform lacks 3.3.0 and then we can drop it entirely for J-turtle which will be able to use at least =3.3.0 from 24.04 and bookworm (and hopefully EPEL9).
Thank you for the additional insights. Is the best course of action to leave the issue open until a decision on Iron has been made and then follow your recommended actions?
The differences between 3.2 and 3.3 are mostly bug fixes (including some memory address fixes), and the change of error handling - rather than exiting and taking downstream packages down it switched to using errno. This is an improvement for edge cases and did not noticeably change the API.
Is the best course of action to leave the issue open until a decision on Iron has been made and then follow your recommended actions?
Yes let's do that. I think it's also worth linking related work back to this issue until the transition is either complete and there is no longer an apriltag or apriltag_vendor package in Rolling in order to capture the entire process. It will be good to have a relatively complete record of such a transition.
Hi @nuclearsandwich,
I am checking in what the current thoughts on vendoring apriltag are - in particular around updating Rolling and Humble to the newer 3.3 release - and what the thoughts for Iron were? Based on:
I wonder if we make this change in Rolling but patch the vendor package in Iron to vendor if the target platform lacks 3.3.0 and then we can drop it entirely for J-turtle which will be able to use at least =3.3.0 from 24.04 and bookworm (and hopefully EPEL9).
I.e. are we good to update Apriltag on released platforms to 3.3?
I.e. are we good to update Apriltag on released platforms to 3.3?
I've just refreshed myself on this issue after the end-of-year holidays. I think that we should do our best to balance preparing for the future with maintaining stability in released distributions.
It probably does not make sense for apriltag itself to add cmake logic that prevents it from building if it is already available upstream which means that we would still need an apriltag_vendor but that would be vendoring a package that also has its own package.xml, which I think is a novelty. This is a good case study for the nascent vendor package REP.
With that in mind here's what I propose we do (none of this is my original idea it's a distillation and endorsement of ideas from upthread and other conversations about maturing and solidifying the software vendoring policy in ROS 2)
- Leave apriltag 3.3 released as-is for Humble, Melodic, and Noetic
- Replace the
apriltagpackage in Rolling with anapriltag_vendorpackage, keeping the version requirement at 3.3 - ROS Iron inherits
apriltag_vendorfrom Rolling - When Rolling shifts to Ubuntu 24.04 bump the version requirement in
apriltag_vendorto match (e.g. 3.4, 3.5) apriltag_vendorwill exist in ROS 2 until all supported platforms provide an acceptable version of apriltag (which means it could last indefinitely) but the version requirement will only be increased to match the oldest upstream version in any tier 1 platform (Ubuntu, for reference)
Overall I'm ok with this. However I think that we need to define what's an acceptable version of apriltag so that we don't end up with it lasting indefinitely because of scope creep.