[Jack-Devel] jack Debian packaging?

[Felipe Sateler]

El 16/03/09 13:25 Paul Davis escribió:
> On Sun, Mar 15, 2009 at 2:18 PM, Adrian Knoth 
<adi at drcomp.erfurt.thur.de>wrote:
> > Hi!
> >
> > I've just seen
> >
> > jackd/configure.ac:
> >
> > echo "WARNING: ON ANY DEBIAN-DERIVED DISTRIBUTION (Debian, Ubuntu etc)"
> > echo "CHANGING THE INSTALLATION PREFIX WILL NOT PRODUCE A WORKING JACK"
> > echo "INSTALL. Please contact the distribution packager for JACK and"
> > echo "ask them to fix their packaging."
> > echo "!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
> > exit 1
> >
> >
> > Since jackd is team-maintained in Debian, I feel responsible for this
> > one.
> >
> > What's wrong with current packaging? (and how do you want it to be
> > changed?)
>
> Ever since JACK was first packaged on debian, it has been done wrong.
>
> Somebody decided to added a "library version"  to the installed .so file,
> so that rather than the used-name of the library file being called
>
>          $prefix/libjack.so.M.m.n
>
> it is called
>
>          $prefix/libjack-0.100.0.so.M.m.n
>
> libjack.so.0.100.0 is a symlink to the -0.100.0. version, not the other way
> around.
>
> Then, all packages of JACK clients on debian (and derived systems) are
> built so that the client has run-time linkage dependency on libjack-0.100.0
> and not on libjack. This was done, it was claimed years ago, "to protect
> clients from changes in the API".

OK, I've made some archaeology on the changelog and it seems that this started 
back in 2002 with bug 149687 in the debian bts. If this is the case, the 
maintainer at that time decided against upstream's versioning 
because 'different "releases" (CVS snapshots actually) aren't guaranteed to 
be binary compatible.' It would appear, based on Paul's answer, that this is 
no longer (if it ever was) the case and that JACK takes seriously the library 
versioning (the M part is what interesting, not so much m or n). Thus, I 
think it would be possible to drop the change.


>
> First of all, it is not the responsibility of a distribution packager to
> "protect clients from changes in the API". Either you do this by consistent
> packaging, or you can't do it at all.

Eeh, you can do it. The used mechanism works inside of Debian, although I 
agree it is suboptimal. It is done with rapidly evolving libraries.

> Secondly, this is not done with (for 
> example) X or NFS, which are about the closest to JACK as examples that
> have both a library *and* a server and the two must be in sync.

The problem is not the sync between client and server. The original maintainer 
either thought that the SOVERSION was not correctly handled back then, or 
didn't really understand library packaging. The change was to prevent that 
other applications (such as ardour) would load an incompatible library.

> Thirdly, 
> this completely ignores standard Unix/Linux/Posix library versioning (the
> M.m.n part of the names above) which is the correct way to manage library
> version dependency. The fact that we (the JACK team) set M, m and n and do
> not change them unless we need to seems to have escaped the entire debian
> packing project. It has never been clear to me what made the original
> Debian packagers of JACK think that they needed to or should or even could
> add their own "versioning" component to the name of the library.
>
> The JACK source tree does not build libjack-0.100.0, and it does not do
> anything with symlinks. The result is that when a user updates their JACK
> system (which they generally need to do because Debian is very slow to pick
> up new versions), they end up with the new library installed as
> libjack.so.M.m.n, whereas clients are still attempting to link to
> libjack-0.100.0.so.M.m.n. Since this does not point (in any way) to the new
> version, clients fail to work.
>
> Preferred solution: drop libjack-<ANYTHING>.so.M.m.n and revert to just
> libjack.so.M.m.n
> Weaker but workable solution: make libjack-0.100.0.so.M.m.n a link to
> libjack.so.M..n rather than the other way around.  Note that "0.100.0" is a
> meaningless name.

This wouldn't work, since SONAME is encoded inside the binary, not only on the 
filename. Thus the dynamic loader would not see the libjack-0.100.0.* name. 
It is effectively the same as the preferred solution.

>
> Thanks for asking. This is one of the most common sources of user confusion
> on the IRC channel #jack and we would surely love to see it fixed after all
> these years.


I think we can make the proposed change. Drop the version encoding in the 
library and package name, since upstream seems to handle SONAME correctly.


Saludos,
Felipe Sateler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20090316/226b3846/attachment-0001.pgp