I'm still not sure if I actually need this. I think this is probably still useful if someone wants to maintain 1.x.x and 2.x.x under the same rosdistro.

I think this is probably still useful if someone wants to maintain 1.x.x and 2.x.x under the same rosdistro.

I think in order to support two different versions in a single rosdistro you would need two separate release tracks which would have two separate patches entries.

Is there an example of this somewhere? I may actually need this.

Is there an example of this somewhere? I may actually need this.

Not as such. The only package I know of which has two different versions in a single rosdistro is behaviortree_cpp which has a separately named behaviortree_cpp_v3 package https://github.com/ros/rosdistro/blob/master/dashing/distribution.yaml#L360-L380

I don't think that any rosdistro tools support two different versions of packages with the same name in a single rosdistro.

So, I'm trying to think about how to build multiple hardware variants out of a single repository.
It seems like it should be possible to run multiple tracks from a single release repo but I'm not sure how you end up with different package names. I'm not sure if I cant patch the #defines from a single package into multiple release repos.

Is there a way for it to generate debian packages with a name like
ros-melodic-trackname-packagename?

I haven't looked at the source yet, but would a patch to support this sort of package naming in the event that trackname != rosdistro be considered for merging?

So, I'm trying to think about how to build multiple hardware variants out of a single repository.

I think this is a good candidate for a question on ROS Answers as it's definitely outside my realm of experience to provide much guidance.

Is there a way for it to generate debian packages with a name like
ros-melodic-trackname-packagename?

The package name for rosdebian and rosrpm packages is exactly ros-ROS_DISTRO-PACKAGE_NAME where ROS_DISTRO is the ros_distro specified in the release track and PACKAGE_NAME is the package name from the package.xml.

Changing the system package name without affecting the ROS package name will create problems. For example, each package name must be unique within the rosdistro before the "ROS-ified" package name is even applied. How would you distinguish different packagename variations when building from source?

I haven't looked at the source yet, but would a patch to support this sort of package naming in the event that trackname != rosdistro be considered for merging?

I think the interaction for packages built in ROS workspaces needs to be well understood before I could review changes on the bloom side.

Releasing two co-installable versions of something into a distribution is rarely supported. If they share any symbols files or other content they will conflict. And any package that depends on them will need to be able to specify specifically which version they need. And if you step back and look at that it's basically you need to change the name of the package. And this is what most projects do. If you want different versions of libraries installable side by side, you release the package with the major version or other version identifier built into the name. This gives you all the namespacing and isolation appropriately, it's easy to reference version A or version B by name.

This pattern is regularly used in the debian ecosystem, fedora ecosystem and many others. See Qt versions, libusb, ect.

In general the primary value of a distribution is that you get a known version of a package which will be compatible with other users. If we start trying to release N copies of a library into the distro they really are actually separate packages with separate versioning requirements etc. It's not actually helpful to downstream users to play games with the naming and force them to do version logic. And the trackname is effectively meaningless to the end user, and is not available in a source workspace. So you depending on the games you play here you could have packages that are unable to build in a source workspace if dependencies depend on both the 1.x and the 2.x series.

So I'd strongly suggest that to this end we not try to support having multiple versions of a package in the rosdistro. If you're maintaining a full branch of the codebase and you want it to be useable side by side it needs to be fully addressable and that mechanism already exists, it's called a package name.

Thanks for the thoughts.

How about if it is the same code revision but there are compile time variations?
Could I patch the package.xml with bloom to set the package name for each hardware config?
Are there any cases where the trackname != the distro name makes sense?