Re: RFS: jansson (updated package)
Petri Lehtinen writes:
> Dear mentors,
Hi,
> I am looking for a sponsor for my package "jansson".
>
> * Package name : jansson
> Version : 1.2-1
> Upstream Author : Petri Lehtinen
> * URL : http://www.digip.org/jansson/
> * License : MIT
> Section : devel
>
> It builds these binary packages:
> libjansson-doc - C library for working with JSON data - documentation
> libjansson0 - C library for working with JSON data
> libjansson0-dev - C library for working with JSON data - development files
>
> The package appears to be lintian clean.
>
> The upload would fix these bugs: 561051
>
> Update: I shortened the package descriptions from the previous
> version, as suggested by Ben Finney. Also, the previous RFS mail
> wasn't as verbose as this one. See below.
>
> My motivation for maintaining this package is: I am the upstream
> author, and would like to see Jansson in Debian to make its users
> happy! There are not many C libraries for JSON manipulation in Debian,
> in fact I can only see libjson-glib, which depends on glib. Jansson
> depends on no external libraries. Moreover, I think Jansson's API is
> superior. This should be apparent as I wrote it! :)
There is also yajl which is in Debian proper and imo it is not that easy to
compete it, though I for one always bet on fair competition ;-)
> This is my first attempted upload to Debian. I tried to follow the
> policy manual and library packaging guide as well as possible, and I
> also have discussed with some Ubuntu MOTUs about the package. I
> decided to go for Debian instead of Ubuntu, as Debian is the ultimate
> upstream for many distributions, not just Ubuntu.
>
> My only real concern right now is that should the -dev package be
> named libjansson0-dev (as the library packaging guide suggests) or
> just libjansson-dev. In the (distant) future, there will be version
> 2.0 of the library, which is API incompatible, so that would justify
> including the SONAME in the -dev package name. OTOH, I don't see many
> packages use this convention. Does it only make things complicated?
Yes, this is doable, but this also makes things (unnecessarily) complicated.
Well maintained libraries provide stable API (public symbols never disappear,
only newly added ones appear over time), so I find it unnecessarily complicated
to upload a library package which is already *known* to change incompatibly in
the distant (or not so distant?) future, and then eventually handle a painful
library transition. Generally, well maintained libraries don't go that way, so
they don't need such complicated schemes like libpkgABI-API{-dev}. When your
library reaches (planned) API stability (that is what libraries are for by the
way;-), then it would make sense to encode SONAME only in the library package,
and leave the -dev one SONAME free.
--
pub 4096R/0E4BD0AB <people.fccf.net/danchev/key pgp.mit.edu>
Reply to: