On Sat, Apr 17, 2010 at 09:25, torbenh <torb...@gmx.de> wrote: > > hi...
Hi Torben. (I'm CCing you because I don't know if you are subscribed). > > i just want to make sure you leave the option open > to package alternative jack versions. > > adi said that you somehow seem to believe that > there cant be virtual packages containing libraries. > > this is not true. > > if you create debian/libjack0.shlibs > and put > ----------------------------------- > libjack 0 WHATEVER > ------------------------------------ > > in it, this will get installed into > /var/libs/dpkg/info/libjack0.shlibs > > and it will result in dh_shlibs generating > WHATEVER as a dependency when it encouters something linked against > libjack.so.0 > > so its pretty easy to make libjack0 a virtual package. > we already have 3 implementations of jack > which are all ABI compatible. > and we really want users to be able to use them. Something like this is used for the ffmpeg package. However, for that to work, virtual packages are not enough. Dependencies on shared libraries are versioned, and versioned depends on virtual packages are not supported by dpkg. For this to work, we would need to have the names of the packages providing the alternative libraries. So, if the default jack is in libjack0, then there could be libjack1-0, libtschack0 packages that provide the different versions (and somehow make the versioning between all three is consistent in the shlibs file: libjack0 (>= a.b.c) | libjack1-0 (>= x.y.z) | libtschack0 (>= f.g.h) ). > > its fine if the default is jack2. but please leave the door open for > people who have problems with jack2 and are better off with tschack. There is additional burden to packaging several versions of jack. Unless someone takes that burden and packages another version of jack, there is no point in making the debian package more complex. Are there debian packages of these other versions of jack around? > > we (upstream) will make sure they are binary compatible. > all symbols added since jack-0.116 are mandated to be weak. > if there are any issues with binary compatibility these are bugs. I'm not sure how weak symbols help binary compatibility. If I understand weak symbols correctly, it enables an application to detect if certain symbols are available and make use of them. How does that ensure that an application built against one version is compatible with another? -- Saludos, Felipe Sateler _______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
