Re: RFS: jansson (updated package)
George Danchev wrote:
> 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 ;-)
Well, yajl is sax-style and only does decoding and encoding, so it
doesn't really compete in the same category :)
> > 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.
Then why even encode the SONAME in the library package name? The
SONAME changes when ABI changes, i.e. a function declaration changes,
a function's semantics change, or struct contents changes (if used
statically or allocated on stack). Each of these means an API breakage
too, right? I can only think of one possible ABI change that doesn't
change the API: a field is added to a struct.
As far as I can see, encoding the SONAME to the -dev package name
makes it possible to also change the API (as it will change anyway
when ABI changes), and make the library transition joyful and not
painful :) The -dev package business is, after all, about what the
packages using Jansson should Build-Depend on, right? We want to
ensure that those packages won't fail to build in the future.
On the other hand, if the upstream has a clear versioning policy on
how version numbers change when a backwards incompatible API change is
made (as Jansson has [1]), there's no need to have the SONAME in the
library package name. Just Build-Depend on a suitable version range
that is guaranteed to have the correct API.
After thinking it over, I agree that it might be silly to upload a
package whose API is *known* to change. I've been delaying the changes
in the hope that I'll discover more things to change. This way the
version number doesn't grow so rapidly.
So, what to do with this? My ultimate goal is to get Jansson into
Debian, and people who read this list must have more experience in
this library packaging business than I have.
Petri
[1] http://wiki.github.com/akheron/jansson/versioning-policy
Reply to: