Bug#884575: ITP: syncthingtray -- a tray applet, plasmoid, and Dolphin integration for Syncthing
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
aviau@debian.org
On Sun, 26 Sept 2021 at 21:33, Nicholas D Steeves <sten@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 <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.
Reply to: