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 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org