Hi Nicholas, hi Alexandre, Am 27.09.21 um 03:27 schrieb Nicholas D Steeves: > By the way, is this your first Debian contribution? If so, welcome! :-)
It is, indeed, besides some bug reports. Thank you. > 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. So. I managed to get the configuration name feature that the upstream author mentioned in the GitHub issue to work. It is possible to add arbitrary suffixes to the library name, the include directories and the CMake config files. This should avoid any name conflicts. The sources are on Salsa. I think a prefix would be nicer, and I think it should not be too hard to add configuration name prefix switch. I would like to check if this is a feasible option. In case it is not too much work and the upstream author is willing to merge those changes, we could get a proper prefix to the package name. Otherwise, I would suggest to stick with a suffix for ease of maintenance. > 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)? I am happy to share the responsibility with a team. Would that mean any additional obligations for me? > 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 ;-) I am a bit confused here. I though libsyncthing is a part of Syncthing Tray. I could not find the sources anywhere else. Are they actually part of some other package? Where do I find the sources? > 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. As I have mentioned above. I'll try to brush up the package with respect to the naming. I'll keep you updated. Regards, Hannah
