"upstream packages" increasingly becoming a problem

Based on PackageTransition - Debian Wiki you probably want Breaks/Replace (with the correct versions) (I didn’t tested it, tough).

To elaborate on this: Conflicts states that both packages can’t be installed at the same time, so for example if the catkin package is installed and you do apt install python-catkin-pkg there is no solution. But with Breaks/Replace it should offer to remove catkin and install python-catkin-pkg instead.

From the list here: "upstream packages" increasingly becoming a problem - #10 by gavanderhoorn two are asking for ROS on Ubuntu 19.10 and all the other would be fixed by declaring the correct relations.

I see two problems here:

  • not having the OR apt repos added (those are missing packages, but should be fine otherwise)
  • having the OR apt repos with broken dependencies (these we can fix)
1 Like

Yeah, that seems worth doing.

You do you propose to do this specifically?

E.g. the Python packages in the ROS apt repo are released from the same sources across all active distros. I don’t see how it could reference a specific version of an upstream package which will be different across distros.

The same applies to at least some ROS packages. And even if they would have distro-specific branches the upstream version could change which we don’t have any control over.

I assume this should work:

Breaks: catkin (<< ${binary:Version}~)
Replaces: catkin (<< ${binary:Version}~)

I.e. replace anything that’s below the current version.

That sounds like a misconception of how releases work, once Ubuntu is released we normally don’t push new upstream versions there. But let’s assume someone adds Debian unstable as an additional apt source and that one has a higher version (again unlikely as the newest version is normally distributed in the OR repos). A proper way here would be to adopt the package names in the OR repo to match the Debian names (and doing the Replaces the other way round) so newer Debian versions should just work (as long as new upstream version are compatible)

:+1: on the discussion here, thanks for that.

@jspricke: let’s get buy-in for your proposed Breaks + Replaces approach and then we can start PRing this.

If I understand it correctly, it wouldn’t help with users not reading documentation and not setting up the OR repositories, but it would help in cases where they do have those setup, but then inadvertently try to install catkin or python-rosdep2?


I would be interested in questions of people not having the OR repos enabled, maybe we can help them as well.

Could you give an example of the kind of output they’d get from apt if/when trying to apt install python3-rosdep2 fi?

I’m pretty sure I’ve seen at least one, but I can’t find it right now. I’ll update when I find it.

Currently at $dayjob but if you have some time I can help you to set up a test repo and try it out. Would make sense anyhow to test we got all combinations.

I might not understand how this is supposed to work. Let’s make this example more concrete. Assuming these lines are added to the catkin_pkg Python package and released to the python-catkin-pkg / python3-catkin-pkg packages in the ROS apt repos.

If the upstream catkin packages is installed with the current version 0.8.0-1ubuntu2 what do you expect to happen if a users attempts to install the ROS Python package? The version constraint (<< ${binary:Version}~) doesn’t seem to apply?

Anyway please create pull requests for this proposal and we can continue the conversation there (since not everyone watching this discourse category might be interested in the technical details).