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 <m...@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/
signature.asc
Description: PGP signature