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
