[RFC] Using pkgconf instead of pkg-config

[Cogitri]

I propose to use pkgconf instead of pkg-config for building. pkgconf has some advantages to pkg-config:

• It's still actively maintained (on https://git.dereferenced.org/pkgconf/pkgconf)
• It generally is faster than pkg-config...
• ...while providing a more accurate dependency graph (which prevents excessive overlinking)

Other distros such as Arch, Fedora, Mageia and most of the BSDs already use pkg-conf. Also see the Arch ML for their thread about this topic: https://lists.archlinux.org/pipermail/arch-dev-public/2018-May/029252.html

[maxice8]

+1 for me i can start working on it

[maxice8]

@void-linux/pkg-committers

[the-maldridge]

Lets do this with alternatives and a slow cutover so that we can migrate people slowly.

[Gottox]

...while providing a more accurate dependency graph (which prevents excessive overlinking)

Overlinking isn't an issue for void, as we use as-needed whenever possible. Nontheless, it might have a positive effect on the build time.

With #3412 we can slowly migrate to pkgconf by replacing the dependency in depending packages. I consider the risk of this change negligible. The worst case are a few broken packages that can be fixed by switching back to pkg-config.

[Cogitri]

Sorry, what's the status on this?

[maxice8]

@Gottox when (and how) will we change to pkgconf ?

[maxice8]

I Have started automatically replacing pkg-config with pkgconf on hostmakedepends= on my script https://github.com/maxice8/meltryllis/commit/c402020b9662042ac26c66fba2845575dbcdb320

[maxice8]

I'd like to revert this:

pkgconf is not bug compatiable with pkg-config, it prefixes all values returned by pkg-config --variable with PC_SYSROOT_DIR prefixed, pkg-config itself requires the ${pc_sysrootdir} variable to be in the .pc file itself this massively breaks most packages cross compilation. That behavior is not in line with the spec.

Doesn't help that pkgconf upstream moved to self-hosting and closed their issue section so i can't search if someone raised that issue up or not and what their response is.

pkg-config is good enough and doesn't break cross packages and follows the spec.

[the-maldridge]

sgtm

[maxice8]

On Sun, Feb 24, 2019 at 06:14:39PM -0800, Michael Aldridge wrote: sgtm -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #3391 (comment)

Taking this comment as opportunity to answer by mail (comfier). I'm not against it but some problems need to be solved: - the wrappers need to be rewritten to deal with it while not breaking pkg-config. - gobject-introspection needs changes to cope with it. We rely on behavior from the spec to do some magic funky stuff to get cross gir working. - Vala problably as well.

[Johnnynator]

Packages that are broken (when Cross compiling, misses every pacakge that depends on libX11):

Not compiling:

• libX11 https://gist.github.com/Johnnynator/b964d709f77ea187c9a06958abc2571d

Wrong install paths

• fuse3
• lastpass-cli
• ndctl
• pcsc-acsccid
• pcsc-ccid
• udftools

[ericonr]

Is it still intended to get this working?

[Cogitri]

As noted in #3391 (comment) this has been reverted.

[ericonr]

@Cogitri do you think the issue can be closed, then? Or is it still a possibility?

[Logarithmus]

@ericonr what about reconsidering pkgconf? Are there only 7 packages broken? If yes then maybe it's better to try fixing them instead of keeping to use technically inferior pkg-config?

[ericonr]

I sure don't want to deal with the churn and take care of fixing any bugs that may appear. And don't revive old issues.

[Logarithmus]

@ericonr OK, seems like there are many packages which will be broken by pkgconf:

this massively breaks most packages cross compilation. That behavior is not in line with the spec.

It would be nice tho either to fix pkgconf to make it match the spec in this aspect or to alter ./xbps-src to not to rely on this behaviour. But someone has to do this dirty job :( Certainly, not anytime soon.

P. S. Arch Linux has been using pkgconf for 3 years, but they don't have to support multiple architectures (Arch is x86_64/i686 only), so their experience isn't applicable to Void.