We had an online discussion that discussed both handling of invalid rosdep keys, as well as managing EOL for old platform versions This issue will only deal with the former.
- Many packages have no valid keys for currently supported Ubuntu releases, but presumably had a valid key in the past. It is not practical to track down exactly when a package went invalid and indicate that in rosdep. What would be practical is to add entries to rosdep for current releases, noting the invalidity. So something like
cpuburn that was previously:
cpuburn:
debian: [cpuburn]
ubuntu: [cpuburn]
becomes:
cpuburn:
debian:
'*': [cpuburn]
bullseye: null
bookworm: null
trixie: null
ubuntu:
'*': [cpuburn]
jammy: null
noble: null
resolute: null
Yes this is not future-proof. When we eventually have a firmer policy on EOL for supporting platform versions, at that point we could remove invalid keys altogether.
2. Because of the similarities, we should do debian and ubuntu changes together.
3. Many time the package is just misnamed, or changed name. It takes time to track down the correct name, and it greatly increases the review time if there are renames in some cases. I would propose that we NOT try to track down the correct name, but instead note the unavailability somewhat mechanically as above. If someone is really using the package, let them find the real name and propose the fix.
4. About 2/3 of the invalid keys are python-* packages. These I presume have been removed, or possibly renamed to python3-* with the deprecation of python2. I would handle them as in point 1 above. However, we could automatically add the equivalent python3-* key if the package exists, and is not currently in rosdep. Any interest in that?
We had an online discussion that discussed both handling of invalid rosdep keys, as well as managing EOL for old platform versions This issue will only deal with the former.
cpuburnthat was previously:becomes:
Yes this is not future-proof. When we eventually have a firmer policy on EOL for supporting platform versions, at that point we could remove invalid keys altogether.
2. Because of the similarities, we should do debian and ubuntu changes together.
3. Many time the package is just misnamed, or changed name. It takes time to track down the correct name, and it greatly increases the review time if there are renames in some cases. I would propose that we NOT try to track down the correct name, but instead note the unavailability somewhat mechanically as above. If someone is really using the package, let them find the real name and propose the fix.
4. About 2/3 of the invalid keys are
python-*packages. These I presume have been removed, or possibly renamed topython3-*with the deprecation of python2. I would handle them as in point 1 above. However, we could automatically add the equivalentpython3-*key if the package exists, and is not currently in rosdep. Any interest in that?