Hello Nicholas, Hannah, > Oh, and Alexandre was my first Debian contact.
Aww. This is giving me Debconf nostalgia <3. > I'm CCing you to ask if you'd appreciate help packaging deps for > Syncthing 1.18.2, Help for packaging new dependencies of syncthing is always welcome! I have the habit of keeping a TODO list in the changelog: - https://salsa.debian.org/go-team/packages/syncthing/-/blob/b356f757a44765ff2bb1e2a53df6d64b08dbdd25/debian/changelog I am not very territorial with my TODO list. Feel free to steal as many tasks as you like. If it ever runs out, I am sure we can add even more things to it ;). At the time of writing this email, there are three things that need to be done: - Bump the version of github.com/shirou/gopsutil/v3/disk in Debian - Package github.com/AudriusButkevicius/recli - Package github.com/flynn-archive/go-shlex Cheers, -- Alexandre Viau av...@debian.org On Sun, 26 Sept 2021 at 21:33, Nicholas D Steeves <s...@debian.org> wrote: > > 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 <v...@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.
