Hey Nicholas, nice to hear that you are still interested.
I have read this BTS entry, as well as the related GitHub issue [1]. Indeed, libc++utilities and libqtutilities are quite generic names. I think, there are three ways to deal with this. 1. Rename the libraries. Build a package for each one. 2. Build a syncthingtray package that includes the libraries and installs them to `/usr/lib/$ARCH/syncthingtray`. This would make use of the multiple tarball support. 3. Acceptance. Keep the names as they are. Build a package for each one. The three approaches have pros and cons. 1. + More specific package name. - More work: requires changing the build process and changes to upstream might be necessary. - Increases long term maintenance cost, since higher complexity increases the chance of errors. - Can break on updates, if upstream does not want to include the changes. 2. + A hypothetical name collision is avoided. o Probably less work than 1. - Additional work: requires a more complicated build process. - Increases long term maintenance cost, since higher complexity increases the chance of errors. - Libraries cannot be used by other packages. (The author has other applications that might be of interest. They use the same libraries.) 3. + Much simpler than 1. and 2. + Debian package is very close to the upstream package. + Low maintenance cost and more stable build process. - A hypothetical name collision can occur. I, would suggest option 3. A name collision, at this point, is just hypothetical, while the drawbacks of the other options are real. I have checked the package database and there is currently no name collision with these package names, and the Debian Policy Manual just requires a name to be unique in Debian [2], which they are. Furthermore, the chance of a name collision is rather small. Yes, libc++utilities is a rather generic name. However, for the same reason you are concerned about the name, most people will not consider to use such a generic name for a project; it is actually a bold move to choose such a name. In case a more important package needs this name, however, the packages can still be renamed. Hence, I do not see a reason to significantly increase the effort of packaging when there is no concrete reason to do so at the moment. There is the saying "done is better than perfect." If you insist, one could add a section to the README.Debian file that the package will be renamed in case the name is needed by a more important package. In any case, I have taken the liberty to create an MVP (minimum viable packaging) for Syncthing Tray and the required libraries [3], which can be improved upon. What are your thoughts? Regards, Hannah [1]: https://github.com/Martchus/cpp-utilities/issues/16 [2]: https://www.debian.org/doc/debian-policy/ch-binary.html#the-package-name [3]: https://salsa.debian.org/rittich/packaging-syncthingtray