[Bug 2053060] Re: Please remove duplicated package

[Mirko Ferrati]

| Sorry to say, but this report currently looks more like "I want a
pony" instead of a planned approach.

Thanks for starting the conversation, I tried to get a meeting to
explain what I wanted (this is my first time doing such a request) but I
was suggested to try and dump my ideas first into a bug ticket and
iterate over it. So let's iterate!

| There is some kind of notation like
| - "in Noetic", which is not an Ubuntu release
| - "PopOS support", not Ubuntu
| Looks like people are confusing Ubuntu with other distros.

This is a verbatim copy of a list of issues, one would have to open each of those to see what they are really complaining inside. I will details those 2 you mentioned as examples.
In ROS community it's common to identify the ROS/Ubuntu pair with the ROS distro naming, https://answers.ros.org/question/353082/missing-packages-after-installing-rosdep-based-on-python3-rosdep2-in-noetic/ starts with the sentence "After the installation of Noetic on ubuntu 20.04, ...". So if you see Noetic -> it pairs always with Ubuntu 20.04. 
PopOS support issue is traced back to the duplication of ROS packages (just taking some relevant sentences from https://answers.ros.org/question/341986/popos-1910-support/ ):
"Please be aware that those are the UpstreamPackages. Those are not compatible with the regular ROS distributions as provided by packages.ros.org."
"Which isn't surprising, as Ubuntu Eoan is not supported by ROS Melodic. The problem was not Pop OS, but the Eoan underlying it."


| "... already providing debian packages from their PPA" reference to this PPA is missing, so we cannot  compare what we are trading for here. Also "since 10+ years ..." doesn't seem to be something urgent to  start addressing 10 days before feature freeze.

Sorry for not putting the explicit PPA, here it is http://packages.ros.org/ros/ubuntu/ .
It's not 10-days urgent for sure! It has to happen before 24.04 goes public or even shortly after, so in the next 60 days. The ROS community will not start using 24.04 until June anyway. 

| This really has to be a spec, not just a bug report, not targeting
24.04 LTS, but 24.10 or a later Ubuntu release. Things to address:

ROS goes out every 2 years with LTS. We can't miss this one or we will
have to wait until 26.04.

| - a list of binary packages is not helpful. This has to be a list of
source packages, best presented as a tree, or a directed graph.

I will start preparing it, I just have to tune a little more my scripts
to generate the data you requested, will add as attachment soon.

| - are we seeding any of these "to be removed" packages in images, like
desktop, or server, what about images maintained by the community?
edubuntu, ubuntu-studio, kubuntu, ...

I don't know how to answer this, isn't this out of our control? Is there
a place where I can trace the usages of those packages to see if they
are downloaded or if they are added to specific images? Honestly, I
can't imagine anything maintained by the community relying on those "to
be removed" packages instead of the official ros.org ones. It basically
goes against the community instead of supporting it.

| - what about packages we want to keep in the distro, but which are
also maintained by robotics folks as duplicates? Yes, I think the
duplicates are also be found in this PPA, not in the distro. We have to
keep packages in the distro for that reason. Common libraries?

I am not sure I understood this question. What I can say is that anytime a library became enough independent from ROS and started being published in Debian, the ros.org PPA was updated to start using the official library. 
There is a single library in a transition stage where it makes sense to keep the one in debian instead of using the one from ros.org (urdfdom). And I am not removing it (while ROS is working on solving the duplication by removing the library on their side). 
I also analyzed the full dependency tree of the packages I want to remove and confirmed that all the usages are inside ROS itself. Which can be read as: nobody uses ROS without putting their packages into ROS.  

| - Assuming we are doing that removal, how do we manage new imports
from Debian, how do we manage new packages that have dependencies only
being found in the robotics PPA?

We automatically block them. It's the point of all of this, to block the roots of the dependency trees so that all the rest is automatically forbidden from entering Ubuntu archives. 
Please be aware, these Debian packages are generated from an automated script that takes the packages from ros.org, converts them to a different naming scheme and republishes them in debian https://salsa.debian.org/robotics-team/ros4debian . With this script and minor manual edits the debian maintainers can put in hundreds of packages in few days, we need to answer with a system that can block hundreds of packages in few minutes.

| - The packages in the archive might not be the newest versions,
however they are provided for all of our architectures, and they are
well tested. Are we ready to loose that support?

ROS provides amd64 and arm64 packages,
https://repo.ros2.org/status_page/ros_iron_default.html
https://repo.ros2.org/status_page/ros_iron_ujv8.html . What would we
lose? I'd rather help them build for more architectures than keep non-
compatible duplicates around.

Well tested -> can you elaborate? what is the testing that debian/Ubuntu
adds on top of the packages from ros.org? Also regarding the next point

| - Is the robotics PPA QA tested? Do your packages have autopkg tests
defined? That's something where you would regress compared to the
current archive.

Can you elaborate? is this a question for MacOS? https://github.com/autopkg/autopkg? 
If this is about https://wiki.debian.org/ContinuousIntegration/autopkgtest , where can I see which tests have been defined? for example in here https://launchpad.net/ubuntu/+source/ros-roscpp-core/0.7.3-1 where do I find those tests? 


| We had several discussions with various upstreams which provide their own distributions in the past, how to handle disto provided and upstream provided binaries. This would be the first project, where we would start removing an entire software stack from the distro. I am skeptical about that, and would at least suggest to look at an approach having two set of packages side-by-side.

I would love to see what solutions were agreed in those cases!
It's quite set in stone that ros.org will not comply with debian rules and Debian will not work on making the 2 set of packages conflicting with each other during apt installation. 
Ideally we would love to put a rule in place in Ubuntu, maybe like: "if someone tries to install a package from ros.org -> mark for removal all the packages from Debian Robotics." so that we are sure we prevent all collisions. 
But still there would be incompatible versions such as non-LTS where we should warn users that they are installing unsupported ros packages and they should not complain to ROS nor to Canonical if those packages do not work.

-- 
You received this bug notification because you are a member of Ubuntu
Package Archive Administrators, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/2053060

Title:
  Please remove duplicated package

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ros2-rcutils/+bug/2053060/+subscriptions