"upstream packages" increasingly becoming a problem

[jspricke]

@dirk-thomas

Also note that some of “our” packages already do declare conflicts with the “upstream” packages, e.g.:

• https://github.com/ros-infrastructure/catkin_pkg/blob/e7a6806b370c9318ce8a792149c8906830ba22e6/stdeb.cfg#L11-L12
• https://github.com/ros-infrastructure/rosdep/blob/2667916b87c77e9386b93bae93bc843d4c20eab4/stdeb.cfg#L10-L11

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.

[jspricke]

@kyrofa

The problem as far as I can tell isn’t going to be solved by adding breaks/conflicts/replaces (or really anything else) to OR packages as the problem is often encountered before the OR deb repo is even added to the sources. Not saying that’s not worth doing, but it’s not going to be a silver bullet.

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)

[kyrofa]

@jspricke

• having the OR apt repos with broken dependencies (these we can fix)

Yeah, that seems worth doing.

[dirk-thomas]

@jspricke

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

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.

[jspricke]

@dirk-thomas

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.

I assume this should work:

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

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

@dirk-thomas

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.

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)

[gavanderhoorn]

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?

[jspricke]

@gavanderhoorn

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 ?

yes.

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

[gavanderhoorn]

@jspricke

@gavanderhoorn

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 ?

yes.

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

@jspricke

I would be interested in questions of people not having the OR repos enable

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.

[jspricke]

@gavanderhoorn

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

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.

[dirk-thomas]

@jspricke

I assume this should work:

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

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

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).