pkg-config / pkgconf BoF
========================

This BoF is to discuss the state of pkg-config and pkgconf in Debian, and the proposal to switch from pkg-config to pkgconf: its benefits and downsides, approaches etc.

pkgconf is a newer, actively maintained implementation of pkg-config that supports more aspects of the pkg-config file specification and provides a library interface that applications can use to incorporate intelligent handling of pkg-config files into themselves (such as build file generators, IDEs, and compilers). Through its pkg-config compatibility interface (activated when it is run as "pkg-config"), it also can completely replace the original implementation.

Debian would benefit from switching to pkgconf by utilising a more complete implementation of pkg-config that handles aspects of .pc files that pkg-config does not. For example, Provides rules and Cflags.private rules are supported, and pkgconf has a better (and less costly) dependency resolver for .pc files.

pkgconf doesn’t depend on glib, making it easier to bootstrap new architectures, since there won't be a cyclic dependency to break (pkg-config → glib → pkg-config).

* http://pkgconf.org/features.html
* https://fedoraproject.org/wiki/Changes/pkgconf_as_system_pkg-config_implementation
* https://packages.gentoo.org/packages/virtual/pkgconfig/dependencies
* Arch replaced pkg-config wrapper scripts with pkgconf personality feature:
    * https://archlinux.org/packages/core/x86_64/pkgconf/
    * https://github.com/archlinux/svntogit-packages/commit/d5437566549e4a96f3bf965965f47351ab0bb6ff
* Postgres and LLVM refuse to use pkg-config partly because it doesn’t support features they may need, but pkgconf seems to

Unrelatedly: DROP the dpkg hook.

Plan
====
 1. Ack the binary package takeover with Tollef
  * Only one implementation is preferrable to having both in Debian to prevent random failover modes
 2. File a bug with the release team (a transition).
 3. Replace in experimental
 4. Rebuild, find issues, send patches
 5. …
 6. Upload to unstable
 7. PROFIT!


Transition proposal email
=========================

Subject: Transition proposal: pkg-config to pkgconf

Hi,

Following a discussion at DebConf, I’d like to officially propose a transition
from pkg-config to pkgconf in Debian.

pkgconf is a newer, actively maintained implementation of pkg-config that
supports more aspects of the pkg-config file specification and provides a
library interface that applications can use to incorporate intelligent
handling of pkg-config files into themselves (such as build file generators,
IDEs, and compilers).

pkgconf is compatible with pkg-config when it is run as "pkg-config", so it
can completely replace the original implementation.

Debian would benefit from switching to pkgconf by utilising a more complete
implementation of pkg-config that handles aspects of .pc files that pkg-config
does not. For example, Provides rules and Cflags.private rules are supported,
and pkgconf has a better (and less costly) dependency resolver for .pc files.

Having a more complete implementation of the pkg-config implementation can
also help convince upstreams like Postgres and LLVM to switch to using
pkg-config instead of their custom scripts like llvm-config.

pkgconf also supports a feature called personalities [1], that can be used to
implement cross-build support without a wrapper script (as currently
implemented in both pkgconf and pkg-config packages).

pkgconf is already used by other major distributions like Fedora, Gentoo and
Arch, so by doing the switch we’ll be aligning ourselves with other
distributions ([2], [3], [4])

Migration plan
==============

We believe that it would in the best interests of Debian to only ship one
pkg-config implementation, so we propose to make pkgconf provide the binary
package pkg-config without a possibility to fall back to the original
implementation. This means that after pkgconf takes over the pkg-config
binary package, all packages depending on pkg-config will be using the pkgconf
implementation without being able to opt-out and use the one from
freedesktop.org. While this may seem limiting, it reduces the probability of
some packages staying with the freedesktop.org implementation indefinitely and
missing out on bug fixes or suffering from other differences in implementation
details in future when pkgconf becomes even more widespread.

In preparation for this migration, we ran a rebuild of all packages depending
on pkg-config and found only very few failures [5], which may or may not be
related to the difference in behaviour between pkg-config and pkgconf. We will
continue investigating them to provide patches during the transition period.

[0]: http://pkgconf.org/features.html
[1]: https://manpages.debian.org/unstable/pkgconf/pkgconf-personality.5.en.html
[2]: https://fedoraproject.org/wiki/Changes/pkgconf_as_system_pkg-config_implementation
[3]: https://packages.gentoo.org/packages/virtual/pkgconfig/dependencies
[4]: https://archlinux.org/packages/core/x86_64/pkgconf/
[5]: http://pkgconf-migration.debian.net/failed.html