Bug#896464: Passing -V as default

[Niels Thykier]

Scott Kitterman:
> 
> 
> On April 23, 2018 10:03:45 PM UTC, "Lisandro Damián Nicanor Pérez Meyer" <perezmeyer at 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