[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#870042: RFS: gsettings-qt/0.1+16.04.20170729-1 [ITP]


I'm not uploading it myself, but there are various things that ought to
be fixed:

a) qtchooser is not needed in Build-Depends, it's an "implementation

b) we don't use a "qtdeclarative5-" prefix for QML modules, but

c) seen while building:
dpkg-gencontrol: warning: Depends field of package libgsettings-qt-dev: unknown substitution variable ${shlibs:Depends}

d) lines like "usr/lib/*/lib*.so*" are way too generic, and they will
   silently adapt to breaking changes like library renaming, or even
   SONAME bump; a way better option is:
   - libfoo1.install: "usr/lib/*/libfoo.so.1" + "usr/lib/*/libfoo.so.1.*"
   - libfoo-dev.install: "usr/lib/*/libfoo.so"

e) the descriptions could be improved:
   - short descriptions don't start with an uppercase letter
   - longer description could say something more...

f) there is no watch file, so upstream does not do releases at all?
   in this case, you need to specify in changelog that you did a new
   upstream snapshot

g) the QML example in the -dev package? that does not seem to logic to
   me, since you would install the QML package to run it, not the -dev
   (which is needed for using the C++ library)

h) all the "Pre-Depends" fields in control should not be needed anymore
   at this point

i) "Format" in copyright should be https now

j) the symbols file needs "Build-Depends-Package:"; also you added an
   entry as mangled (line 35), while the rest of the file is with
   unmangled symbols (and no old commented entries, please)

k) the tests don't seem to be run at all?

l) the package with the QML module could be "Multi-Arch: same", and
   most probably the -dev package too (but needs to be checked)

m) strictly speaking, there is no need to have this under the qt-kde
   umbrella, since you already put it under collab-maint, and the
   prospected users are other packages in the pkg-deepin team;
   collab-maint with you as single maintainer, or pkg-deepin, would
   be better choices IMHO

n) considering (f) above, the patches, and the logs of the upstream
   repository (especially that few names are not Canonical employees
   anymore), I have some doubt whether this software is still
   maintained/fixed/worked on at all, and thus that it would be
   unmaintained code in Debian right from the first upload

That should be enough notes for now; as general recommendation, please
check the build logs, and fix the lintian issues when possible (info
tags included).

Pino Toscano

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: