control: reassign -1 kf6-config
control: retitle -1 Merge libkf6config-bin into libkf6config6 since its 
contents is all arch-dependent and soname coinstallable

This is a follow-up to :
- https://bugs.debian.org/1098408
For reference, regarding kconfig_compiler :
- https://bugs.debian.org/887452

Summary of our discussion at DebConf25 :

How kconf_update works :
- kf config is a framework for applications to manage upgrades/migrations of 
their data between versions
- it runs on application launch by the end-user when the application was built 
against the KF Config framework
- the application will link to the libKF6ConfigCore library which will look for 
the kconf_update binary in (code in src/core/kconfig.cpp in 
KConfig::checkUpdate()) and run it when appropriate
- kconf_update looks for update commands to be run that are shipped by that 
application above linking against libKF6ConfigCore :
   - either from /usr/share/kconf_update/ for arch-independent data listing 
scripts to run (.upd) or scripts themselves
   - or from /usr/lib/${ARCH}/kconf_update_bin/ for arch dependent binaries

Current status :
- libkf6configcore6 is Multi-Arch: same
- libkf6configcore6 recommends libkf6config-bin (= ${binary:Version})
- libkf6config-bin has no Multi-Arch qualifier
- libkf6config-bin depends on libkf6configcore6 (from ${shlibs:Depends})
- kconf_update and in fact all of libkf6config-bin is shipped in an 
arch-dependent path also containing the lib soname version as can be seen from 
libkf6config-bin contents :
    /usr/bin/kreadconfig6
    /usr/bin/kwriteconfig6
    /usr/lib/x86_64-linux-gnu/libexec/kf6/kconf_update
    /usr/share/doc/libkf6config-bin/changelog.Debian.gz
    /usr/share/doc/libkf6config-bin/copyright
    /usr/share/lintian/overrides/libkf6config-bin

Proposed solution :
- Merge the contents of libkf6config-bin into the Multi-Arch: same 
libkf6configcore6. This will respect the policy to have the lib coinstallabile 
accross sonames since all paths from libkf6config-bin have the soname in them.
- Document why we did this in debian/README.multiarch


--
Aurélien

Reply via email to