Re: RFS: jansson - C library for encoding, decoding and manipulating JSON data
On Sat, Apr 09, 2011 at 10:18:08PM -0300, David Bremner wrote:
On Sat, 9 Apr 2011 15:26:20 +0200, Alessandro Ghedini al3x...@gmail.com
wrote:
Thanks for your review.
Uploaded. Feel free to contact me directly for future jansson uploads.
Great, thank you :)
I took the liberty of pushing a tag debian/2.0.1-1 to collab-maint
(corresponding to version I uploaded). Feel free to delete if the naming
convention doesn't suit you, or whatever.
That's fine
Cheers
--
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110410122820.GA1810@PC-Ale.WAG300N
Re: RFS: jansson - C library for encoding, decoding and manipulating JSON data
On Wed, 6 Apr 2011 23:28:58 +0200, Alessandro Ghedini al3x...@gmail.com wrote: It builds these binary packages: libjansson4 - C library for encoding, decoding and manipulating JSON data libjansson4-dev - C library for encoding, decoding and manipulating JSON data (dev) libjansson4-doc - C library for encoding, decoding and manipulating JSON data (doc) Some comments: 1) Don't put the soname in the name of the -dev package, unless you are really sure it is needed. It complicates SONAME transitions. Unfortunately library packaging docs are in flux right now, but see for example the message http://lists.debian.org/debian-mentors/2011/03/msg00357.html 2) Same for the doc file; I see less downsides here to the versioning, but convention is to to have unversioned doc files. 3) I see you install docs into /usr/share/doc/jansson instead of /usr/share/libjansson4-doc. I'm not sure that this is a bug, but it is bit unusual. Can you explain/justify this? 4) It could be nice to install test/bin/json_process.c as an example (see e.g. man dh_installexamples); no makefile or anything is needed. 5) licenscheck --copyright src suggests one more copyright holder that could be added to debian/copyright. 6) I'm not sure about saying C library rather than just library in the short description. Perhaps it betrays my age, but for me that is the default. But I'm willing to convinced if there is some advantage to the user. That is all I see now. Feel free to just push changes to git.debian.org; I prefer to work from the git repo in any case. David pgpRGx8UQdThC.pgp Description: PGP signature
Re: RFS: jansson - C library for encoding, decoding and manipulating JSON data
Hi David,
On Sat, Apr 09, 2011 at 09:16:24AM -0300, David Bremner wrote:
On Wed, 6 Apr 2011 23:28:58 +0200, Alessandro Ghedini al3x...@gmail.com
wrote:
It builds these binary packages:
libjansson4 - C library for encoding, decoding and manipulating JSON data
libjansson4-dev - C library for encoding, decoding and manipulating JSON
data (dev)
libjansson4-doc - C library for encoding, decoding and manipulating JSON
data (doc)
Some comments:
1) Don't put the soname in the name of the -dev package, unless you are
really sure it is needed. It complicates SONAME transitions.
Unfortunately library packaging docs are in flux right now, but see
for example the message
http://lists.debian.org/debian-mentors/2011/03/msg00357.html
2) Same for the doc file; I see less downsides here to the versioning, but
convention is to to have unversioned doc files.
There were some API changes between version 1.2 and 1.3 (which is the
version I originally packaged) and I thought it was better to use a
versioned -dev package, just to prevent issues, but since v2.0 has been
released this is not needed anymore (according to upstream the API should
be quite stable now).
For the versioned -doc package I simply followed the docs. Anyway, I've now
renamed both the packages.
3) I see you install docs into /usr/share/doc/jansson instead of
/usr/share/libjansson4-doc. I'm not sure that this is a bug, but it
is bit unusual. Can you explain/justify this?
I took a couple of packages as examples (don't remember which ones, though)
that were doing this, when I started packaging jansson. But now that you
pointed out, seems quite logical using *.docs and installing under
doc/libjansson-doc instead of doc/jansson.
4) It could be nice to install
test/bin/json_process.c
as an example (see e.g. man dh_installexamples); no makefile or anything
is needed.
Indeed.
5) licenscheck --copyright src suggests one more copyright holder that
could be added to debian/copyright.
Thanks for spotting this.
6) I'm not sure about saying C library rather than just library in the
short description. Perhaps it betrays my age, but for me that is the
default. But I'm willing to convinced if there is some advantage to
the user.
Just copied the upstream's description here. Also, I do prefer when
library packages explicitly says which language they are intended for (e.g.
C, C++, etc), since it saves me a bit of research. But maybe it's just me :)
That is all I see now. Feel free to just push changes to git.debian.org;
I prefer to work from the git repo in any case.
Thanks for your review.
Cheers
--
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110409132620.GA5717@PC-Ale.WAG300N
Re: RFS: jansson - C library for encoding, decoding and manipulating JSON data
On Sat, 9 Apr 2011 15:26:20 +0200, Alessandro Ghedini al3x...@gmail.com wrote: Thanks for your review. Uploaded. Feel free to contact me directly for future jansson uploads. I took the liberty of pushing a tag debian/2.0.1-1 to collab-maint (corresponding to version I uploaded). Feel free to delete if the naming convention doesn't suit you, or whatever. d pgpJPl4qHkGpb.pgp Description: PGP signature
RFS: jansson - C library for encoding, decoding and manipulating JSON data
Dear mentors,
I am looking for a sponsor for my package jansson.
* Package name: jansson
Version : 2.0.1
Upstream Author : Petri Lehtinen pe...@digip.org
* URL : http://www.digip.org/jansson/
* License : Expat
Section : libs
It builds these binary packages:
libjansson4 - C library for encoding, decoding and manipulating JSON data
libjansson4-dev - C library for encoding, decoding and manipulating JSON data
(dev)
libjansson4-doc - C library for encoding, decoding and manipulating JSON data
(doc)
The package appears to be lintian clean.
The upload would fix these bugs: 561051 (ITP)
My motivation for maintaining this package is: Thanks to its intuitive and
simple API I think this is a very valid alternative to the IMHO more complex
json-c which is already in the archive. Many new interesting open source
projects are using this library so it will probably be needed at some point
in the future.
The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/j/jansson
- Source repository: deb-src http://mentors.debian.net/debian unstable main
- dget http://mentors.debian.net/debian/pool/main/j/jansson/jansson_2.0.1-1.dsc
I would be glad if someone uploaded this package for me.
Kind regards
Alessandro Ghedini
--
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110406212858.GB3518@PC-Ale.WAG300N
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
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
RFS: jansson (updated package)
Dear mentors, 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! :) 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? The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/j/jansson - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/j/jansson/jansson_1.2-1.dsc I would be glad if someone uploaded this package for me. Kind regards Petri Lehtinen -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: jansson (updated package)
Err, I got the subject wrong. This is a new package, not an update. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
RFS: jansson
Dear mentors, I am looking for a sponsor for my package jansson. * Package name: jansson Version : 1.2-1 Upstream Author : Petri Lehtinen pe...@digip.org * URL : http://www.digip.org/jansson/ * License : MIT Section : devel It builds these binary packages: libjansson-doc - C library for encoding, decoding and manipulating JSON data - documentation libjansson0 - C library for encoding, decoding and manipulating JSON data libjansson0-dev - C library for encoding, decoding and manipulating JSON data - development files The package appears to be lintian clean. The upload would fix these bugs: 561051 My motivation for maintaining this package is: I am the upstream author and would like to see this in Debian, too. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/j/jansson - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/j/jansson/jansson_1.2-1.dsc I would be glad if someone uploaded this package for me. Kind regards Petri Lehtinen -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: jansson
Petri Lehtinen pe...@digip.org writes: It builds these binary packages: libjansson-doc - C library for encoding, decoding and manipulating JSON data - documentation libjansson0 - C library for encoding, decoding and manipulating JSON data libjansson0-dev - C library for encoding, decoding and manipulating JSON data - development files It would probably be simpler, and no less useful, if instead of “encoding, decoding and manipulating JSON data” the synopses used “working with JSON data”. The longer exposition could go into the full package description. -- \ “It's easy to play any musical instrument: all you have to do | `\ is touch the right key at the right time and the instrument | _o__)will play itself.” —Johann Sebastian Bach | Ben Finney -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: jansson
Ben Finney wrote: Petri Lehtinen pe...@digip.org writes: It builds these binary packages: libjansson-doc - C library for encoding, decoding and manipulating JSON data - documentation libjansson0 - C library for encoding, decoding and manipulating JSON data libjansson0-dev - C library for encoding, decoding and manipulating JSON data - development files It would probably be simpler, and no less useful, if instead of “encoding, decoding and manipulating JSON data” the synopses used “working with JSON data”. The longer exposition could go into the full package description. Yeah. I actually had to write the short descriptions to the e-mail by hand as the RFS template generator just cut them to something like 82 characters. When I reupload, should I use the same version or add a changelog entry with increased Debian revision? -- Petri Lehtinen Software Specialist Inoi Oy Tel. : +358 40 758 0229 Email: petri.lehti...@inoi.fi -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: jansson
Petri Lehtinen pe...@digip.org writes: When I reupload, should I use the same version or add a changelog entry with increased Debian revision? That's the way that makes sense to me, since you have already released the package and announced it for inspection. Any further changes should be in a later release to simplify comparing them. Don't forget to use the ‘-v’ option to ‘dpkg-genchanges’ (or whatever tool you're using to wrap that command) so all the relevant changelog entries are included. Some other DDs prefer a different practise, and there isn't strong consensus; so, once your package has a sponsor, you should work with that person's preference on this matter. -- \ “Whatever a man prays for, he prays for a miracle. Every prayer | `\ reduces itself to this: “Great God, grant that twice two be not | _o__) four.”” —Ivan Turgenev | Ben Finney -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
