On Sun, Apr 21, 22:25, Adam Borowski wrote > On Sun, Apr 21, 2019 at 05:11:05PM +0200, Andre Noll wrote: > > That's just because I misread section 8.1 of the Debian Policy Manual. > > I've renamed the -dev package to liblopsub-dev. > > Not sure if you'd want the _source_ package to have a simple soname-less > name as well; I would but that's up to you -- that'd be nicer and make > having only-one-version transitions easier; on the other hand a > soname-encoded source name is better when there's a need for multiple > coinstallable versions. There are no plans for multiple incompatible versions. Instead, the plan is to keep the ABI compatible forever, using symbol versioning if necessary. Therefore I've changed the name of the source package from liblopsub1 to liblopsub. > * installation instructions don't really belong in the man page -- if you > can read it, you've already managed to install the package. Right. OTOH, the instructions might be helpful for the web page, which is just the html version of lopsub.7. I've moved the instructions to the README file, and adjusted lopsub.7 slightly. > * please copy the description for liblopsub1 to liblopsub-dev; it currently > says just "This package contains the development environment for the > lopsub library." It's pointless to require the user to check the other > package -- other libraries alter merely the last part. Also, it's -dev > what users pull by hand. Done. > * is there a reason for shipping the static library? Static linking is > frowned upon in a distribution -- whenever the library gets updated, > every reverse dependency has to be recompiled; this is especially nasty > for security updates. The main reason I've kept it is that the Debian Policy Manual says The static library (libraryname.a) is usually provided in addition to the shared version. But yes, nobody needs the static library, so I've removed it from the build. > * (bonus) The nicely documented process for building the example looks > like something that could be turned into an autopkgtest. Unlike > build-time tests, autopkgtests are run against installed packages, > the way an user would. That's of course extra effort, by no means > required -- but, extra testing is always good. I guess I need some help here. https://people.debian.org/~mpitt/autopkgtest/README.package-tests.html describes the format of debian/tests/control, but does not say how to set up the test environment. Since the tests do not need to run as root, and do not access the network either, a simple chroot environment should be fine. But how do I set up such an environment for use with autopkgtest? > But in general, the package already seems to be in a releasable state. > Could you please change "UNRELEASED" to "unstable" so it can be uploaded? Done. Please have a final look. If everything is fine, I can merge the various topic branches to master (so that master becomes what is pu now), and tag the result as v1.0.3. Thanks 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