Puh, here goes another lengthy mail... On Sat, Apr 17, 2010 at 20:31:46 (CEST), Felipe Sateler wrote: > On Sat, Apr 17, 2010 at 09:25, torbenh <torb...@gmx.de> wrote: >> 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) ).
I've had a longer conversation with torben about this and my earlier suggestion on irc. While we all agreed that from a distribution POV we shouldn't provide more than one libjack implementation, he suggested a further variant of the two already proposed approaches, which would produce a shlibs file like this: libjack0 (>= a.b.c) | libjack-0.116 and the libjack-0.116 would then be a virtual package, provided by all jack implementations. It would them indicate a provided binary interface. All (alternative) implementations would then need to conflict/replace on libjack-0.116. This makes libjack-0.116 effectively a pure virtual implementation like mail-transport-agent, cf. with policy §7.6.2. Also note that we probably should then get this discussed on debian-devel for inclusion in the official list of virtual packages as indicated in §3.6 and .  http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt I have never seen such a virtual package for shared libraries in the wild so far. Before we do that, we would need to check if the alternative implementations need to conflict on libjack0 explicitly, or if conflict/providing on libjack-0.116 is sufficient. NB: every jack daemon implementation would still need to carry a very strict shlibs.local file to ensure that the daemon matches the library it is compiled against! NB2: this requires any applications with special requirements on a specific jack implementation to ship a shlibs.local file. >> 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? The actual packaging is not that complex. The trouble comes with supporting/testing all possible combinations of applications and libjack/jackd implementations. >> 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? It doesn't ensure anything in applications, but upstream considers such applications buggy that need to be fixed. The weak symbol approach isn't really supported by dpkg-shlibdeps/dpkg-gensymbols, so we need to take special care for them. While we are at dpkg-gensymbols: in the irc conversation, Torben said that he considers the leaked internal symbols as something that needs to be fixed and asked them to be reported upstream. Jonas, please keep this in mind, and the special situation of the 0.116 ABI freeze. AFAIUI, the current jack packages calls dh_makeshlibdeps with '-V' (i.e., without version bound). This seems very wrong to me, and should rather be bound to the 0.116 version, and not to each and every new upload. As for symbol files, please reconsider the situation with these pieces of information, I still think that symbol files don't have much benefit without further work on hiding internal symbol, which torben seems happy to consider for inclusion! -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 _______________________________________________ pkg-multimedia-maintainers mailing list email@example.com http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers