jack for lenny

[Free Ekanayaka]

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

  RT> I've taken a look at the changes in libjack-dev. 

Thanks a lot, nice job.

  RT> I'm comparing here
  RT> version 0.109 against version 0.116. Here is 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.

  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.

  RT> Now I'm stopping reviewing. These 2 changes leave me to the insight that
  RT> the shlib bump is fully warranted and we cannot let binaries built
  RT> against 0.116 enter testing.

That's probably not too bad after all, it's another argument for
migrating 0.116 to testing :)

Ciao!

Free