Scott Kitterman: > > > On April 23, 2018 10:03:45 PM UTC, "Lisandro Damián Nicanor Pérez Meyer" > <perezme...@gmail.com> wrote: >> If I understand correctly and, let's suppose, libQtFoo 5.10.2 is built >> with a patched compat 12, then all applications rebuilt against 5.10.2 >> would require at very least 5.10.2 even if symbols files allowed it to >> depend on a minor version. >>
As far as I understand it, symbols files overrule shlibs. I.e. if your symbols files covers all the symbols required by the application, the version will be derived from the symbols file. dpkg-shlibdeps(1) seems to agree with this: > DESCRIPTION > dpkg-shlibdeps calculates shared library dependencies for > executables named in its arguments. The dependencies are added to the > substitution variables > file debian/substvars as variable names shlibs:dependency-field where > dependency-field is a dependency field name. Any other variables > starting with > shlibs: are removed from the file. > > dpkg-shlibdeps has two possible sources of information to > generate dependency information. Either symbols files or shlibs files. For > each binary that > dpkg-shlibdeps analyzes, it finds out the list of libraries that it's > linked with. Then, for each library, it looks up either the symbols file, > or the > shlibs file (if the former doesn't exist or if > debian/shlibs.local contains the relevant dependency). Both files are > supposed to be provided by the > library package and should thus be available as > /var/lib/dpkg/info/package.symbols or /var/lib/dpkg/info/package.shlibs. The > package name is identified in > two steps: find the library file on the system (looking in the same > directories that ld.so would use), then use dpkg -S library-file to lookup > the package > providing the library. Note the "Then, for each library, it looks up either the symbols file, or the shlibs file (if the former doesn't exist or if debian/shlibs.local contains the relevant dependency)." To me that implies that the symbols file is preferred over the shlibs file when both are present. Further, in the concrete case, dh_makeshlibs will still allow you to override the default when you happen to know that upstream has a sane versioning scheme. >> [...] >> >> The only thing I don't know from this is iif symbols files dependency >> info is totally discarded or the dependency on qtbase-abi-x-y-z would >> still be get trough them for packages using private API. >> >> Niels: like in [1] we use dpkg-symbols' >> "alternative-dependency.template" to track packages using private API. >> As long as this is kept then the change, I think, should be ok. >> >> [1] >> <https://salsa.debian.org/qt-kde-team/qt/qtbase/blob/master/debian/libqt5core5a.symbols> > > If that's true, I doubt C++ symbols files are worth the trouble. > > Scott K > I think this case would still work as it used too (e.g. ok for .debs and ignored for .udebs - but as I recall, qtbase-abi does not have any udebs and should not be concerned by that) Thanks, ~Niels
