| Message ID | 20260317112407.312819-1-kory.maincent@bootlin.com |
|---|---|
| State | Under Review |
| Headers | show |
| Series | default-providers: switch pkgconfig provider to pkgconf | expand |
On 17 Mar 2026, at 11:24, Kory Maincent via lists.openembedded.org <kory.maincent=bootlin.com@lists.openembedded.org> wrote: > > pkg-config has been unmaintained since 2017. Major Linux distributions > such as Fedora, Debian, Alpine, and Arch Linux have all switched to > pkgconf as their default pkg-config implementation. Upstream projects > no longer use or recommend pkg-config. There is no reason for Yocto > to keep lagging behind and continue using a dead tool. > > Switch the preferred providers for pkgconfig, nativesdk-pkgconfig and > pkgconfig-native to pkgconf, aligning with the broader ecosystem. I’ve been working on this migration during this cycle and literally last night did one last built of the universe with pkgconfig vs pkgconf. It’s not quite as simple as just switching the providers, but it’s close. > Should we keep making pkgconf emulate the legacy pkg-config behavior? > At this point, projects have had sufficient time to adopt native pkgconf > compatibility, so it may be worth dropping the wrappers and letting > pkgconf behave as its own tool. This is a bigger question. The pkgconf maintainers have Opinions on how —variable and sysroots interact and simply dropping the fdo behaviour does result in build breakage. Ross
Hello Ross, On Tue, 17 Mar 2026 13:37:48 +0000 Ross Burton <Ross.Burton@arm.com> wrote: > On 17 Mar 2026, at 11:24, Kory Maincent via lists.openembedded.org > <kory.maincent=bootlin.com@lists.openembedded.org> wrote: > > > > pkg-config has been unmaintained since 2017. Major Linux distributions > > such as Fedora, Debian, Alpine, and Arch Linux have all switched to > > pkgconf as their default pkg-config implementation. Upstream projects > > no longer use or recommend pkg-config. There is no reason for Yocto > > to keep lagging behind and continue using a dead tool. > > > > Switch the preferred providers for pkgconfig, nativesdk-pkgconfig and > > pkgconfig-native to pkgconf, aligning with the broader ecosystem. > > I’ve been working on this migration during this cycle and literally last > night did one last built of the universe with pkgconfig vs pkgconf. It’s not > quite as simple as just switching the providers, but it’s close. Oh, great! > > Should we keep making pkgconf emulate the legacy pkg-config behavior? > > At this point, projects have had sufficient time to adopt native pkgconf > > compatibility, so it may be worth dropping the wrappers and letting > > pkgconf behave as its own tool. > > This is a bigger question. The pkgconf maintainers have Opinions on how > —variable and sysroots interact and simply dropping the fdo behaviour does > result in build breakage. I know it will raise some discussion, but maybe we could align with Buildroot choice on this topic: https://github.com/buildroot/buildroot/blob/master/package/pkgconf/0001-Only-prefix-with-the-sysroot-a-subset-of-variables.patch Regards,
On Tue, Mar 17, 2026 at 7:04 AM Kory Maincent via lists.openembedded.org <kory.maincent=bootlin.com@lists.openembedded.org> wrote: > Hello Ross, > > On Tue, 17 Mar 2026 13:37:48 +0000 > Ross Burton <Ross.Burton@arm.com> wrote: > > > On 17 Mar 2026, at 11:24, Kory Maincent via lists.openembedded.org > > <kory.maincent=bootlin.com@lists.openembedded.org> wrote: > > > > > > pkg-config has been unmaintained since 2017. Major Linux distributions > > > such as Fedora, Debian, Alpine, and Arch Linux have all switched to > > > pkgconf as their default pkg-config implementation. Upstream projects > > > no longer use or recommend pkg-config. There is no reason for Yocto > > > to keep lagging behind and continue using a dead tool. > > > > > > Switch the preferred providers for pkgconfig, nativesdk-pkgconfig and > > > pkgconfig-native to pkgconf, aligning with the broader ecosystem. > > > > I’ve been working on this migration during this cycle and literally last > > night did one last built of the universe with pkgconfig vs pkgconf. It’s > not > > quite as simple as just switching the providers, but it’s close. > > Oh, great! > > > > Should we keep making pkgconf emulate the legacy pkg-config behavior? > > > At this point, projects have had sufficient time to adopt native > pkgconf > > > compatibility, so it may be worth dropping the wrappers and letting > > > pkgconf behave as its own tool. > > > > This is a bigger question. The pkgconf maintainers have Opinions on how > > —variable and sysroots interact and simply dropping the fdo behaviour > does > > result in build breakage. > > I know it will raise some discussion, but maybe we could align with > Buildroot > choice on this topic: > > https://github.com/buildroot/buildroot/blob/master/package/pkgconf/0001-Only-prefix-with-the-sysroot-a-subset-of-variables.patch > > Whats upstreams view on this patch ? it seems that it will be custom from distro to distro. I wonder if upstream could consider an option to add a list of such dirs via envvar or some other mechanism to insert it. > Regards, > -- > Köry Maincent, Bootlin > Embedded Linux and kernel engineering > https://bootlin.com > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#233324): > https://lists.openembedded.org/g/openembedded-core/message/233324 > Mute This Topic: https://lists.openembedded.org/mt/118362272/1997914 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [ > raj.khem@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- > >
diff --git a/meta/conf/distro/include/default-providers.inc b/meta/conf/distro/include/default-providers.inc index 5101ad78f8..c0a5d1c75e 100644 --- a/meta/conf/distro/include/default-providers.inc +++ b/meta/conf/distro/include/default-providers.inc @@ -56,9 +56,9 @@ PREFERRED_PROVIDER_getopt ?= "util-linux-getopt" PREFERRED_PROVIDER_openssl ?= "openssl" PREFERRED_PROVIDER_openssl-native ?= "openssl-native" PREFERRED_PROVIDER_nativesdk-openssl ?= "nativesdk-openssl" -PREFERRED_PROVIDER_pkgconfig ?= "pkgconfig" -PREFERRED_PROVIDER_nativesdk-pkgconfig ?= "nativesdk-pkgconfig" -PREFERRED_PROVIDER_pkgconfig-native ?= "pkgconfig-native" +PREFERRED_PROVIDER_pkgconfig ?= "pkgconf" +PREFERRED_PROVIDER_nativesdk-pkgconfig ?= "nativesdk-pkgconf" +PREFERRED_PROVIDER_pkgconfig-native ?= "pkgconf-native" PREFERRED_RPROVIDER_initd-functions ?= "initscripts" PREFERRED_PROVIDER_nativesdk-mesa ?= "nativesdk-mesa"
pkg-config has been unmaintained since 2017. Major Linux distributions such as Fedora, Debian, Alpine, and Arch Linux have all switched to pkgconf as their default pkg-config implementation. Upstream projects no longer use or recommend pkg-config. There is no reason for Yocto to keep lagging behind and continue using a dead tool. Switch the preferred providers for pkgconfig, nativesdk-pkgconfig and pkgconfig-native to pkgconf, aligning with the broader ecosystem. Signed-off-by: Kory Maincent <kory.maincent@bootlin.com> --- There is also the question of the pkgconf wrappers: https://git.openembedded.org/openembedded-core/tree/meta/recipes-devtools/pkgconf/pkgconf Should we keep making pkgconf emulate the legacy pkg-config behavior? At this point, projects have had sufficient time to adopt native pkgconf compatibility, so it may be worth dropping the wrappers and letting pkgconf behave as its own tool. --- meta/conf/distro/include/default-providers.inc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)