On Sat, Mar 30, 23:58, Adam Borowski wrote
> On Thu, Mar 28, 2019 at 11:41:45AM +0100, Andre Noll wrote:
> > * Package name : lopsub
> > Version : 1.0.2
>
> Such a version means a native package; only software written specifically
> for Debian which makes no sense outside it should use the native format.
> Even if you're both upstream and the packager, a non-native format is
> helpful in case someone other than you would upload a fix.
>
> This library is certainly not something for Debian only, thus please append
> "-1" to the version, and set debian/source/format to "3.0 (quilt)" (which,
> despite the name, doesn't require actually using quilt).
Sure, I just wasn't aware of this convention, and that "3.0 (quilt)"
is the right choice for a package like lopsub. One question: With this
change applied, dpkg-buildpackage wants the upstream tarball in the
parent directory. I guess I'm supposed to run git archive here to
create it as part of the before-build hook, but I couldn't figure
out where this hook is defined.
> > Upstream Author : Andre Noll <maan@tuebingen.mpg.de>
> > * URL : http://people.tuebingen.mpg.de/maan/lopsub/
> > * License : (L)GPLv3
>
> It would be nice to mention more prominently what parts are GPLv3-ed and
> which are LGPLv3-ed.
The library is LGPLv3 while the lopsubgen executable is GPLv3. The
source code generated by lopsubgen is licensed with a simple
all-permissive license. See lopsub.7 for more information. I've
changed debian/copyright to make this distinction stand out a bit more.
> I'd recommend running "lintian -i" which gives a long descriptive message
> for every warning, including hints how to fix.
Point. This was a very helpful hint indeed. With the long descriptions,
it was easy to squash the remaining few warnings.
> I see a static library installed by the package. Those shouldn't generally
> be used unless you're doing something special -- static linking makes
> security and bugfix updates extremely tedious. Libraries should also be
> split into separate binary packages, with lib${name}dev providing
> development files while lib${name}${so} the runtime lib.
Yes, I had this concern as well. I'll change the build system to
create a shared library instead and split the binary package as you
suggest. I'll follow up with another reply when it's ready.
Thanks a bunch for the review
Andre
--
Max Planck Institute for Developmental Biology
Max-Planck-Ring 5, 72076 Tübingen, Germany. Phone: (+49) 7071 601 829
http://people.tuebingen.mpg.de/maan/
Attachment:
signature.asc
Description: PGP signature