Hi Hannah! Reply follows inline. Hi Alexandre! I'm CCing you to ask if you'd appreciate help packaging deps for Syncthing 1.18.2, because the working copy of Syncthing Tray that Hannah prepared has an embedded copy of this version's libsyncthing that should be unbundled. Hannah Rittich <void@rittich.net> writes: > Hey Nicholas, > > nice to hear that you are still interested. > Yes, definitely! Long ago Alexandre Viau (Syncthing maintainer in Debian) convinced me of the usefulness of Syncthing, and a more friendly and convenient UI for our KDE Plasma users is *long overdue*. Oh, and Alexandre was my first Debian contact. By the way, is this your first Debian contribution? If so, welcome! :-) > 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. > So option #1 is patching the library, and not using a different package name at the dpkg level. I wonder about namespacing the dependencies' names at the dpkg level, without patching the library? Eg: src:marchus-cpp-utilities (which generates bin:marchus-libc++utilities5). What do you think? I think this would be less confusing to users/devs, and I feel like it's likely that there will be a cpp-utilities from glibc or LLVM somewhere in the future. What I mean by "confusing" is I really don't think that it's appropriate for a helper library to grab such an authoritative name, except in Flatpaks, and such containerised packages, of course! ;-) If #3 ever becomes a real issue, I hope that our popcon stats will help convince upstream to DTRT. > 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? > Wow! Yes, I will definitely sponsor your work :-) How do you feel about comaintaining these packages in the "debian" group (used to be called collab-maint)? Syncthing for Debian tends to lag behind upstream, and we'll need to ignore or remove the embedded copy of libsyncthing in Syncthing Tray. In terms of long-term maintenance it looks like Syncthing Tray updates will need to block for Syncthing (and its new deps) uploads. I forget if I uploaded the packages or not, but at some point I worked on packaging new Golang deps for Syncthing, and it wasn't as difficult as I had expected. I'll wait for Alexandre's ACK before asking you if you're also interested in Golang packaging ;-) Hannah, thank you so much for your work. Your enthusiasm (and work ethic) is inspiring, and I'd like to do whatever I can to make your Debian experience rewarding. Your work looks excellent, and I don't expect to find any issues, but I'll need to take time to carefully examine everything, do some QA tests, and make sure the paperwork-type stuff is all in order. Also, we don't need to wait to unbundle libsyncthing before uploading cpp-utilities and qtutilities (ideally prefixed with 'martchus-' at the dpkg level), and those packages will need to migrate through the NEW queue before Syncthing Tray can be uploaded. Regards, Nicholas P.S. If ever I seem to disappear, please ping me on a weekly basis. The next reliable window of free time that I'll have is in mid-October, and until then I'll do my best to reply quickly.
Attachment:
signature.asc
Description: PGP signature