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

Re: OpenStreetMap Software

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


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

The libosmium2-dev binary package has no dependencies, only a Recommends
on libosmium2-doc and Suggests on the other packages in the new osmium

Package: libosmium2-dev
Source: libosmium
Version: 2.0.0-1
Architecture: amd64
Maintainer: Debian GIS Project <pkg-grass-devel@lists.alioth.debian.org>
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


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 <dev@openstreetmap.org>
>> 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 <jochen@topf.org>
>> 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,


 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Reply to: