jack for lenny

[Reinhard Tartler]

Free Ekanayaka <free at 64studio.com> writes:

> Hi Reinhard,
>
> |--==> On Mon, 12 Jan 2009 11:02:31 +0100, Reinhard Tartler <siretart at tauware.de> said:
>
>   RT> Reinhard Tartler <siretart at tauware.de> writes:
>   >>Well, from what I see from the package, it seems that the API (and
>   >>therefore the ABI) did change (at least in a backwards compatible way),
>   >>else you wouldn't have to bump SHLIBS, no?
>
> Sorry I'm confused, what do you mean by bump shlibs? The soname of the
> jack library is the same in both 0.109 and 0.116, that is 0.0.28.
>
> http://packages.debian.org/lenny/amd64/libjack0/filelist
> http://packages.debian.org/sid/amd64/libjack0/filelist

Well, let's see:

>> debdiff  libjack0_0.109.2-3_i386.deb libjack0_0.116.1-3_i386.deb
[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files in second .deb but not in first
-------------------------------------
-rw-r--r--  root/root   /usr/lib/jack/jack_net.so
-rw-r--r--  root/root   /usr/lib/libjackserver.so.0.0.28
lrwxrwxrwx  root/root   /usr/lib/libjackserver.so.0 -> libjackserver.so.0.0.28

Control files: lines which differ (wdiff format)
------------------------------------------------
Conflicts: jackd (>> [-0.109.2-3),-] {+0.116.1-3),+} jackd (<< [-0.109.2-3),-] {+0.116.1-3),+} libjack0.100.0-0 (<< 0.102.20-2), libjack0.80.0-0
Depends: libasound2 (>> 1.0.16), libc6 (>= 2.7-1), libfreebob0 (>= [-1.0.7)-] {+1.0.7), libsamplerate0+}
{+Homepage: http://jackaudio.org/+}
Installed-Size: [-292-] {+484+}
Maintainer: Debian Multimedia [-Team <debian-multimedia at lists.debian.org>-] {+Maintainers <pkg-multimedia-maintainers at lists.alioth.debian.org>+}
Suggests: jackd (= [-0.109.2-3)-] {+0.116.1-3)+}
Version: [-0.109.2-3-] {+0.116.1-3+}

So a new library was included: libjackserver.so. This is in any case a
new functionality, and new code always introduces the risk of
introducing new bugs.

However if we examine the shlibs file of the .debs:

>> dpkg-deb -I libjack0_0.109.2-3_i386.deb shlibs
libjack 0 libjack0 (>= 0.109.2)

>> dpkg-deb -I libjack0_0.116.1-3_i386.deb shlibs
libjackserver 0 libjack0 (>= 0.116.1)
libjack 0 libjack0 (>= 0.116.1)

This means that for packages built against the version in unstable,
dpkg-shlibdeps will generate the dependency "libjack0 (>= 0.116.1)".
Packages built against that version cannot transition to testing because
that dependency cannot be fulfilled.

That is what I mean with 'shlibs bump'.


>   RT> I'm comparing here version 0.109 against version 0.116. Here is
>   RT> the diffstat:
>
>   >>>diffstat /tmp/jack.diff
>   RT>  jack.h      |  380 +++++++++++++++++++++++++++++++++++++-----------------------
>   RT>  midiport.h  |    7 +
>   RT>  thread.h    |   23 +++
>   RT>  transport.h |   24 +++
>   RT>  types.h     |    4 
>   RT>  5 files changed, 293 insertions(+), 145 deletions(-)
>
>   RT> And here the diff itself:
>
>   RT> There vast majority of the changes seem to be due to renames in
>   RT> jack.h.
>
> As far as I can tell the old names are all preserved, probably with a
> runtime warning.

too bad that there is no easy way of verifying this. And that's a pretty
good reason for the RT to reject the new upstream version. :-(

>   RT> However there are also two additions in thread.h:
>
>   RT> int jack_client_real_time_priority (jack_client_t*);
>   RT> int jack_client_max_real_time_priority (jack_client_t*);
>
>   RT> thread.h changes the binary structure of jack_position_t.
>
> That could be a problem, maybe we should ask upstream for
> clarifications.

Why asking? It is pretty clear with this examination  that we cannot
lower the shlibs requirements. This means that we are pretty stuck now :-(

>   RT> Now I'm stopping reviewing. These 2 changes leave me to the
>   RT> insight that the shlib bump is fully warranted and we cannot let
>   RT> binaries built against 0.116 enter testing.
>
> That's probably not too bad after all, it's another argument for
> migrating 0.116 to testing :)

it is an good argument to do something. And we have collected arguments
now to not include the new upstream version. Perhaps you can demonstrate
what amount of testing has been done with the version 0.116? That would
be our only chance to convince the release team to accept the new
version.

If we don't manage to convince them until this week end, I'd propose to
reintroduce 0.109.2 to unstable and keep 0.116 in experimental only.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4