asterisk t-p-u upload

[Ron]

Hi,

I'm happy to consider this grounds for requesting a freeze exception
for vpb-driver, the changes since 4.2.36 that affect Debian users are
all in the 'too minor to request one otherwise' category, so I hadn't
done so previously.  This code has been in freeze upstream for quite
some months, so the changes are all deliberately minimal and suitable
for propagation to production users.

I definitely should relax the -V with the next upload, this is an
oversight/bug on my part.  The strict versioning was appropriate when
the packages were first created, but that hasn't been true since the
first upload to the distro, it's just gone unnoticed until now.  I'll
hold off on an upload to do that until I hear how you'd like to deal
with this for Lenny.  vpb-driver already has enough time in unstable
and is eligible to migrate immediately if you choose to go that way.

Cheers,
Ron


On Fri, Dec 26, 2008 at 02:08:59AM +0200, Faidon Liambotis wrote:
> Hi,
> 
> I've prepared a fix for #507883, an RC bug for asterisk.
> 
> Unfortunately, one of its dependencies, libvpb0, had a new upload in
> unstable (v4.2.38-1 vs. v4.2.36-1 in lenny) and uses  "dh_makeshlibs -V"
> with no symbol files, which resulted in new shlibs for asterisk.
> 
> Those libvpb0 changes are minor -mostly fixing GCC 4.4 FTBFS due to
> missing headers- and do not change the ABI at all (verified both by
> looking at the source and by comparing the exported symbols).
> 
> So, I can see four solutions:
>   a) The obvious: upload asterisk to t-p-u.
>   b) Fix libvpb0's shlibs to state the reality (">= 4.2.36"), upload,
>      wait for it to build on all architectures and then upload asterisk.
>      Versioned build-dep is obviously not an option here.
>   c) Push vpb-driver 4.2.38-1 to lenny.
>      asterisk is the only rev-dep in Debian, Ron is also upstream.
>      But I can see how this can be a problem during our hard freeze :)
>   d) Override the shlibs with debian/shlibs.local.
> 
> If there's no real rush and Ron agrees, I'd say that (c) is the best
> solution. I have no real problem with (d) either, despite its uglyness.
> 
> What's the preferred way in your opinion?
> 
> Thanks and happy holidays,
> Faidon
>