Since I am stuck with maintaining the pkg-config autoconf macros, I have updated them to suggest using pkgconf instead of pkg-config, since pkg-config is clearly not maintained anymore.

Users are better served by being pointed to a maintained pkg-config implementation...

Incidentally, how do we officially retire the original pkg-config? Maybe @mupuf can help?

@ariadne impressive feat deprecating the package you outright wrote a clone of, but then when it hits 8 fucking years without a release...

@ariadne @mupuf Would you consider blessing a fork of it, essentially giving it away? I see value in a copyleft pkg-config and keeping the autoconf macros alive, and can offer to maintain it going forward. Or at least move pkg.m4 out of the abandoned pkg-config repo into something that can be maintained.

@jas @mupuf Software freedom is not served by re-fragmenting the pkg-config ecosystem, and I will not be cooperating with anybody with such agenda.

Now that basically nobody is using the original, it is time to deprecate it so that we can focus on improving the pkg-config format to provide the necessary data to support things like FFI.

With that said, if the GNU autoconf maintainers would like to take over maintenance of pkg.m4 (which has remained copyleft the entire time in my tree), that would be welcome.

@jas @ariadne @mupuf The problem with pkg-config is that nobody was working on it long before pkgconf came into existence. Heck, even the project it came from mostly spurned it (Debian).

The adoption of pkgconf across everywhere is somewhat my fault, but I'm not sorry about it. The implementation is actually complete, and features that had been asked for over a decade were finally completed and made available.

I prefer copyleft as well, but I also want good software.

@neal @jas @mupuf

I debated for a long time whether to use LGPL or ISC for pkgconf in the early days.

The thing is, pkgconf is infrastructure software. It is *boring*. Making it copyleft just makes life harder for everyone when some platforms either avoid pkg-config entirely (in lieu of that horrid CMake thing) or write broken clones of it (like u-config). That is why I went with ISC, so that we could solve this problem once and for all.

Fragmenting the ecosystem yet again does not benefit the commons, and therefore cannot benefit software freedom.

@ariadne @jas @mupuf Yes, I understood why in *this* case, it was permissively licensed. I've been bitten by the broken reimplementations of pkg-config in the past too, so having something that everyone can consume without "objections" is much more important.

Today, pkgconf is effectively the reference implementation that people care about. And that's a *good* thing!

@neal @jas @mupuf

Exactly. I wanted pkg-config to be sane *everywhere*, and for the most part, now it is. That is the point.

@ariadne @jas @mupuf Guix is still using freedesktop pkg-config, so it’s not “basically nobody” (although it seems a patch was submitted in 2024 to switch to pkgconf by default, I’m not sure what the status of that is)

@noisytoot @jas @mupuf Guix can enjoy having an increasingly buggy and unmaintained pkg-config then. I don't know what to tell them.

@neal @jas @ariadne @mupuf pkg-config did not come from Debian.

@jamesh @neal @jas @mupuf correct, it came from GNOME as an evolution of gnome-config.

https://mail.gnome.org/archives/gtk-devel-list/2000-June/msg00023.html

@ariadne @neal @jas @mupuf Anyway: pointing users at pkgconf if they don't have a pkg-config installed seems like a reasonable option these days.

It's the implementation that most people actually use these days, so prompting them to install the old pkg-config is just setting them up for more compatibility problems.

@jamesh @neal @jas @mupuf given that the original pkg-config generates increasingly wrong output when used in modern distributions...

@ariadne @jamesh @jas @mupuf Using the original pkg-config will also basically break RPM dependency generation these days, too. We have been relying on pkgconf features for almost a decade now.

@neal @jamesh @jas @mupuf I found a forgotten about patch in Guix to switch to pkgconf where they literally reverted hundreds of hackfixes that they no longer need because pkgconf does the right thing.

but freedom!

@ariadne @jamesh @jas @mupuf When it comes to permissively licensed projects, trust in the people matters a whole lot more. Honestly, I trust *you* to be a decent steward of a permissively licensed project. There aren't a lot of people on that list for me.

@neal @jamesh @jas @mupuf but... pkgconf PRO with AI features in the CLOUD for only $9.99/month :(((((((

@ariadne @jamesh @jas @mupuf

@neal @jamesh @jas @mupuf ok pkgconf enterprise will be $199/month and have a useless electron app as a frontend :D

@neal @jamesh @jas @mupuf (i am kidding, i seriously have no intention on ever making a proprietary pkgconf, because the entire idea would be self-defeating, and honestly, what the fuck would it do?)

@ariadne @neal @jas @mupuf You could presumably use AI to replace those fiddly .pc files and the dependency solver.

An LLM should be able to produce a plausible set of compiler arguments.

@jamesh @neal @jas @mupuf james no

@ariadne @jamesh @jas @mupuf

@ariadne @jamesh @jas @mupuf With the right pitch, anything is possible. Haven't you seen the stuff that gets VC funding these days?

@ariadne
The point is that middle managers can use it as an excuse to lay off their staff. (And then rehire them at double the rate when everything is broken)
@neal @jamesh @jas @mupuf

@Valdus @neal @jamesh @jas @mupuf so how would pkgconf do that

@ariadne
<insert marketing buzzwords here>
@neal @jamesh @jas @mupuf

@Valdus @ariadne @jamesh @jas @mupuf Well, one of the first open source SBOM tools was part of pkgconf. Just because it is unknown doesn't mean it isn't there. So I suppose you could go the extra mile and say pkgconf could enable extra layers of assurance for compliance and quality assurance by enabling toolchains to apply JIT rules to the dependency graph to enable policy guarantees about the software being built and released.

@neal @Valdus @jamesh @jas @mupuf neal no

@ariadne Hmm, I'm more on the X. Org foundation side of Freedesktop. Honestly, the best answer I can muster is to ask Daniel Stone (daniels on OFTC).