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

Re: libphonenumber packaging, libre2, ...

On 02/06/14 12:25, Fredrik Roubert wrote:
> On 27/05/14 15:59, tony mancill wrote:
>> * it has a build-dep on libre2-dev, which is currently only in
>> experimental
> That's explained here:
> http://alioth.debian.org/scm/loggerhead/collab-maint/re2/trunk/view/head:/debian/README.Debian

Stefano, we are now at the point where another package needs to link
against re2 - could you please make an upload to unstable or add any
other comments about the situation?

I tried building libre2 manually on wheezy, one of the test cases failed:

obj/test/parse_test                      FAIL; Output:
................................re2/testing/parse_test.cc:214: Check
failed: (string(tests[i].parse)) == (s)Regexp: \s
parse: cc{0x9-0xd 0x20} s: cc{0x9-0xa 0xc-0xd 0x20} flag=1676

> On Thu, May 29, 2014 at 8:43 PM, Daniel Pocock <daniel@pocock.com.au> wrote:
>> Fredrik indicated upstream would welcome improvement to the packaging
>> files.
> Yes, just send code reviews to me. Or, if they're about the
> CMakeLists.txt file, better to Philippe Liard
> <philip.liard@gmail.com>, who actually knows CMake ...

I've spent some time going over this.  Here is my diff - you could just
take my whole debian/* and dump it on top of yours (notice some files


Rather than keeping this in debian/patches, you probably want to apply
this directly in SVN, I think this is the fix for the issue Tony noticed
with boost system:


I also made an upload to mentors so it is easy for people to review


Here are some things that need fixing in SVN:

- the content that was in debian/changelog should be in a top-level
ChangeLog file called changelog.txt - the debian/changelog file should
only be changed when somebody does an upload to Debian, it only needs to
mention things that change in the package (e.g. "New upstream version",
or "initial release of JavaScript sub-package")

- distribution of a source tarball - we can autogenerate source tarballs
from the tags in the github mirror:
or could somebody put source tarballs (without any binary JARs inside)
in the Google Code download page?

- remove binary JARs from SVN so they don't end up in the autogenerated
source tree (see the lintian alerts on the mentors link to see the

- the typos

One thing stands out for me - the package numbering, e.g.
libphonenumber5, libphonenumber6, ...

The SONAME in the file appears correct:
$ objdump -p ./cpp/build/libphonenumber.so | grep SONAME
  SONAME               libphonenumber.so.6

If you change the ABI number regularly, then it will be hard to push
updates to stable distributions (e.g. Debian stable, Ubuntu LTS, EPEL).
 Ideally, if updates are just data changes (to recognize new area codes
and numbering plan changes) then they would be in some separate package
that can be distributed through $(stable)-updates - just like anti-virus
patterns, timezones, etc:

The binary ABI and the developer API would stay the same for a given
Linux version.  I don't want to deter you from adding new features or
make it more tedious to support, but would it be possible to distribute
the pattern data separately in such a manner?

The other problem with the package name is that each time there is a new
package name anywhere in the control file (e.g. a libphonenumber7
package) then the next upload to Debian will need to go in the FTP NEW
queue for manual approval, that adds a delay of 1-4 weeks.  If the
package names haven't changed, then uploads to Debian (and propagation
to Ubuntu) happen automatically within a few hours.  Usually if this
happens no more than once per year it is OK.

If the version number is really significant, maybe the Java packages
should also be named libphonenumber${VERSION}-java?  Does anybody care
either way?

This source file:


changes during the build.  If it is an auto-generated file, maybe it
should not be in SVN at all as it will always be recreated when needed?
 There are various other files like this (*.cc) that are not in SVN.

One thing I haven't look at yet is the JavaScript code - we should make
a libjs-phonenumber.deb package containing that code too.

I've done a first upload to the NEW queue today, there seems to be quite
a backlog there so I thought it would be good to get it in the queue
while we continue refining this.

Reply to: