The remaining cases could be marked as abandoned packages and somebody could take over the maintainership (I think there already is a process for abandoned packages).
See OrphanedPackage - ROS Wiki and Maintaining and releasing orphaned packages . But the purpose of this initiative is/was to release abandoned functional into “new” ROS distributions, not to fix them when broken. Of course the boundaries are not always clear, but in many cases we only have access to existing gbp repositories and not upstream.
that never really became official policy (the REP PR was withdrawn).
The main concern with the REP was that it’s a lot of text, but dead meat already, especially in ROS one, and people just have to talk more and get engaged. The group very much exists and has the required permissions to act, though I don’t know how active anyone is. I’m certainly not doing much work on that front (and I don’t think there is a lot to do right now).
especially regarding the reservations @v4hn has, that it might not be possible or would take an unknown amount of time to get all packages released in a way that rolling release distro users like @Mike_Purvis can relatively easy build a ROS stack from source?
That was not my point at all! Please, please, pretty please go ahead and test/fork upstream where necessary and pull-request (if possible backward-compatible) patches there! In cases where upstream does not merge the patches within a short time window the purpose of the github ros-o organization is to collect such forks for the future. In some cases you will find that such forks already exist, though granted, not yet for most of the open setuptools-patches that were reported here.
There have been ideas for setting up a rosdistro-compatible yaml-register with ros-o overlays, but that is not implemented as of today.
we could do something like
find ... -exec sed -i
Please don’t. There are various other patches needed already on Ubuntu 22.04 and Debian testing (running locally) and other current rolling release distributions. This kind of patch approach will not work but add more noise. It’s just as bad as RoboStack’s patch folder in that regard.
rosinstall_generator ... --upstream
to clarify: for the cases where maintainers merged the patches but were hesitant/forgot to run bloom this will just break with the same errors because it checks out the release tags.
You actually need --upstream-development instead.
Some users will definitely prefer to run with upstream’s releases and hand-pick unreleased patches, but getting everything to run from the latest commits is the best way forward especially for rolling-release in my opinion, also because many repositories do not commit to their ros one branches a lot anymore or have CI in place to prevent merging broken commits in the first place.