On 03/11/2015 07:14 PM, Jochen Topf wrote: > Hi! > > On Mi, Mär 11, 2015 at 06:18:49 +0100, Sebastiaan Couwenberg wrote: >> The libosmium package is basically ready, the last outstanding issue is >> the preferred content of the Upstream-Contact field in the copyright file. > > Looking at the 'control' file just now and I have some issues: > * Is "Section: science" right? OSM doesn't really have anything to do with > science.
This is the recommended section for GIS packages as documented in the policy: http://pkg-grass.alioth.debian.org/policy/policy.html#debian-control Note that this is the section for the source package only, different sections are used for the binary packages. I don't agree that OSM doesn't have anything to do with science. OSM is relevant in the geography field of science. > * I am not sure about the 'Build-Depends'. Libosmium2-dev doesn't really > have to be built because it is a header-only lib. It depends on what you are > doing which dependencies you need, but those are really dependencies for > programs depending on libosmium, not dependencies of libosmium itself. Some > dependencies are needed for running the tests or to build the examples or > the documentation. The build dependencies are there because they are required for the cmake build. The libosmium2-dev binary package has no dependencies, only a Recommends on libosmium2-doc and Suggests on the other packages in the new osmium family: Package: libosmium2-dev Source: libosmium Version: 2.0.0-1 Architecture: amd64 Maintainer: Debian GIS Project <[email protected]> Installed-Size: 1038 Recommends: libosmium2-doc Suggests: osmium-tool, osmium-contrib, node-osmium, pyosmium Section: libdevel Priority: optional Homepage: http://osmcode.org/libosmium/ Description: C++ framework for working with OSM data files The build dependencies are mostly required for building the examples which is a good sanity check for the package builds. The built examples are not installed, only their source is. > * I suggest removing "osmium-tool" and "osmium-contrib" from the "Suggests" > list. Those are simply "users" of libosmium, I don't think we want to > list every package that uses libosmium in the Suggests list. Similar for > other packages. I don't want to include all users of libosmium, only the direct relatives in the new Osmium family. While these Suggest would be more appropriate for a libosmium shared library package, this is the closest thing we've got. The Debian Policy specifies Suggests as follows: " This is used to declare that one package may be more useful with one or more others. Using this field tells the packaging system and the user that the listed packages are related to this one and can perhaps enhance its usefulness, but that installing this one without them is perfectly reasonable. " https://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps I added the Suggest to the rest of the new Osmium family with that in mind. Since I don't feel strongly about it, I'm perfectly happy to drop them again if they bother you. > * All the other packages (osmium-tool etc.) should probably declare > build-dependency on libosmium2-dev. Yes, but I've not had a change to continue with those packages yet. I can do that now libosmium is basically ready. > For some reason git-buildpackage doesn't find the dependency packages on > my system. I get errors like > Err http://ftp.de.debian.org/debian/ jessie/main libosmpbf-dev amd64 1.3.3-2 > 404 Not Found > so I couldn't look at the package myself yet. That looks like an outdated mirror or APT cache. The version in the repo is 1.3.3-2+b1. I suspect running `apt-get update` will solve the issue, otherwise try a different mirror. >> This is currently: >> >> Osmium Developers <[email protected]> >> >> And I'm tempted to change it to the contact URL: >> >> Osmium Developers (http://osmcode.org/contact) >> >> While for the (old) osmium package it's >> >> Jochen Topf <[email protected]> >> >> What is your preference as upstream developer? > > I think the link to http://osmcode.org/contact is best. This gives us a level > of indirections that allows some flexibility to direct different kinds of > requests to different channels and one place where we can change the contact. I've updated the Upstream-Contact field in the copyright file, and pushed my changes for this and the above. The package is ready for an upload to unstable in my view. I'll continue with the other packages using my local APT repo in the mean time. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
