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
==============
I believe that it would in the best interests of Debian to only ship one pkg-config implementation, so I 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, I 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. I will perform another rebuild and 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
--
Cheers,
Andrej
It seems like the proposal went mostly unnoticed. Any comments,
ideas, anything?
Most importantly, I need a green light from the current pkg-config
maintainer (Tollef) to proceed with the plan.
Meanwhile, I have uploaded an updated version of the package which
dropped the crosswrapper, and instead uses the "personalities"
feature to implement its functionality. The package also no longer
needs a dpkg hook, as it ships a per-architecture symlinks in
arch-specific packages.
On Sun, 24 Jul 2022, at 17:33, Andrej Shadura wrote:
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).
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.
Migration plan
==============
I believe that it would in the best interests of Debian to only ship one pkg-config implementation, so I 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, I 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. I will
perform another rebuild and continue investigating them to provide patches during the transition period.
It seems like the proposal went mostly unnoticed. Any comments, ideas, anything?
Hi,
It seems like the proposal went mostly unnoticed. Any comments, ideas, anything?
Meanwhile, I have uploaded an updated version of the package which dropped the crosswrapper, and instead uses the "personalities" feature to implement its functionality. The package also no longer needs a dpkg hook, as it ships a per-architecturesymlinks in arch-specific packages.
symlinks in arch-specific packages.Meanwhile, I have uploaded an updated version of the package which dropped the crosswrapper, and instead uses the "personalities" feature to implement its functionality. The package also no longer needs a dpkg hook, as it ships a per-architecture
I would like to understand how the cross stuff works with this
personalities thing, but it may be a while before I get round to
it. Again I shall assume that you know what you are doing :-)
If Helmut is happy then I'm sure it's good.
Beware that to be compatible with what pkg-config does (and what PKG_CHECK_MODULES wants), the cross-tools need to be prefixed with a
GNU tuple, and *not* a multiarch tuple. So in particular for i386, you
will need to provide /usr/bin/i686-linux-gnu-pkg-config (and presumably
a matching personality).
In other words, this is ${DEB_HOST_GNU_TYPE}-pkg-config and not ${DEB_HOST_MULTIARCH}-pkg-config. This matches the pattern used for
other cross-tools like compilers.
You might want to *also* provide ${DEB_HOST_MULTIARCH}-pkg-config, if they differ, but it is ${DEB_HOST_GNU_TYPE}-pkg-config that is canonically used.
The idea is that e.g. pkgconf:amd64 provides /usr/bin/x86_64-linux-gnu-pkg-config, which is a symlink to pkgconf,
and /usr/share/pkgconfig/personality.d/x86_64-linux-gnu.personality,
which defines DefaultSearchPaths and SystemLibraryPaths to be appropriate values for amd64.
Most importantly, I need a green light from the current pkg-config
maintainer (Tollef) to proceed with the plan.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 13:11:35 |
| Calls: | 12,100 |
| Files: | 15,003 |
| Messages: | 6,518,006 |