Hi Hannah, and anyone else reading this, Update: qtforkawesome is currently waiting in NEW, and I'm currently testing the latest upstream syncthingtray. I haven't moved the project to the Salsa (old collab-maint) group yet, but you can find it with the fork relationship on salsa between your work and mine. Sorry for the delay, the questions in this email were also discussed at various other sites towards the end of 2021, and I didn't see the need to send this draft until now. Hannah Rittich <void@rittich.net> writes: > On 21/11/2021 22:13, Nicholas D Steeves wrote: > > Currently, the Syncthing sources are neither included in the upstream > tarballs nor in the upstream git repo. They can be pulled into the > source tree by using the git submodule, but this does not happen unless > you do this explicitly. > > Nevertheless, to be sure I have added the `submodules = False` to the > `gbp.conf` file. This ensures that the submodules will never be included > in a tarball built by gbp. > > If this situation changes, we might need to change the git repository to > the gbp import-orig workflow, but for now we should be able to keep it > as it is. > >> 2) Use a build-system config key to explicitly disable this functionality. > > Done. > Thanks much appreciated! The principle here is thus: should the maintainers disappear, it should be easy for someone else to take up the baton and resume work with minimal pitfalls. [snip] >>> - in the syncthingtray package the "package-name-doesnt-match-sonames >>> libsyncthingconnector1.1.10 libsyncthingmodel1.1.10 >>> libsyncthingwidgets1.1.10". Since these are quite specific libraries >>> that are only used for Syncthing Tray, I do not see a point in >>> making separate binary packages for each of them. Hence, I would >>> suggest to ignore these warnings for now. >>> >> >> At this time I'm not thinking about this issue; Let's return to this >> question after the two dependencies have been uploaded. Policy will >> need to be consulted >> >> https://www.debian.org/doc/debian-policy/ch-sharedlibs.html >> >> Be it resolved that the current state is indeed the correct direction, a >> minimum solution is a lintian override. > > Okay. > The salient questions here are "are they private libraries?" and "do they have any kind of stable ABI?" For the former, yes, for practical purposes, and to the latter, no they don't have any kind of stable ABI. Thus I've chosen to go with a lintian override. Various colleagues have also expressed that it may be necessary to cut these libs from the system library path...if ftpmasters don't see an issue, no further work will be required at this time. It is possible that Policy may one day prohibit this, but that's a worry for later! >> Additionally, no Debian package should bundle fonts (or font-icons). > > Why? Which part of the policy manual are you referring to? What are your > concerns regarding pre-rendered icons? > This is mostly a question related to martchus-qtforkawesome packaging if I remember correctly. Policy § 11.8.5.1 "Fonts of any type supported by the X Window System must be in a separate binary package from any executables, libraries, or documentation". The font-icons hack is an interesting case because while they're a font they intuitively seem to be icons. The 'fonts-font-awesome' is the package that fulfills this requirement, and I remain hopeful that ftpmasters will approve martchus-qtforkawesome with Syncthing as prior art, even though both packages embed what are technically fonts. There's a dialectic between the work people publish, and Policy, and this case definitely affects Policy. As for pre-rendering, I'm sure you've noticed that the majority of documentation overwhelmingly supports regeneration of everything from the most sourceful form... For example, for fonts: TTF, OTF, BDF, PFB, FNT, and WOFF are output formats, and not source (https://wiki.debian.org/Fonts). To answer what you may be thinking, yes, font-icons may only be fonts due the output format of their build system. Thus, I suspect that the following loophole exists: If a font-icon source has a DFSG-free license, this means that another project has the right to to export the font source into another format, such as SVG. SVG can be losslessly modified, and thus I believe it could be argued that SVG may be considered high-quality source, and that the font source to SVG format conversion is a non-issue. On the other hand, I don't think that rasterised icons (lossy) qualify for this loophole when lossless source is available. There have been many discussions about the freeness of lossy graphics on the mailing lists over the years, if you're interested. 'hope this answers your questions! Thank you once again for all of your work on this and related dependencies. Regards, Nicholas
Attachment:
signature.asc
Description: PGP signature