@ariadne @DG0YT @andrew_shadura out of interest, how much of CDCL loop does the solver (re-)implement?

@ignaloidas @andrew_shadura @DG0YT it is not a SAT solver.

@ariadne @andrew_shadura @DG0YT i’m not sure there’s much distinction tbh, you may think it’s not but from what I’ve seen most dependency resolvers end up with many parts of what a SAT solver would be

@ariadne they did what? Why. Why would they do it.

@ariadne ah, a classic. 👨‍🍳😘

@ariadne calling jbicha an "end-user" ....

@ariadne I hope debian listens to your explanation and does the right thing.

@ah I am not up to date on the who's who of Debian.

@ariadne @andrew_shadura Bisecting won't work if development went through a series of regressions and fixes.

@ariadne This seems like a complete and utter shitshow on the part of Debian and the maintainer. Add in Ubuntu's nonsense and I'm going through non-Debian-based distros looking for a new primary one.

@ariadne damn :(

@ariadne wouldn't it make sense to propose a flag that keeps the old behavior --broken-dependency-tree-fix-me that maintainers can add to propose a smooth transition ? Because of the distributed nature of Debian, bumping pkgconf does not trigger a mass rebuild, so they can't even identify, let alone fix, all .pc files at once.

@Aissen not needed. all they need to do is fix debhelper or whatever it is called to use pkgconf --print-provides when generating dependency data

@Aissen i am also not willing to carry technical debt for distributions which have had *checks notes* 14 years to migrate to pkgconf --print-provides

@ariadne haha, I completely missed that aspect!

@ariadne

debian decided to revert a commit which makes the solver treat Requires.private as a weak dependency node if –static is not requested.

this is NOT conformant with how pkg-config has ever been intended to work. that it used to work was a bug that is now fixed.

wait, really? I always thought of this as a really annoying flaw in pkg-config, and pkgconf not doing this as its primary advantage over pkg-config. It’s annoying because when writing a Guix package for a shared library one has to propagate all its shared library dependencies pulled in via pkg-config to any dependents transitively as well, which makes no sense, since the build process does not need these transitive dependencies at all unless you’re doing static linking. In my own library’s .pc file I had to refrain from using Requires.private properly and hardcode build-time detected linker flags in Libs.private instead just to avoid this.

@kimapr we added requires.internal for this. it does exactly what you want.

@ariadne

Well, I had moving of Required.private depends to -static subpackages on my TODO list but wanted to ask you first. Guess that answers part of my questions

@kimapr basically in pkgconf 2:

- requires = necessary for either shared or static linking (always required to be in DAG)
- requires.private = necessary for static linking and --cflags (always required to be in DAG due to --cflags)
- requires.internal = should be used for static linking (required to be in DAG if --static, otherwise missing nodes are tolerated)

@kimapr in the very early days of pkgconf, we did experiment with making requires.private tolerable if --static was not present, but discovered quickly why pkg-config always walks .private nodes when evaluating --cflags.

@ariadne does pkg-config support it? the guide page doesn’t ever mention it

@kimapr no, but pkg-config also does not properly support Provides. it does not matter, almost the entire world is using pkgconf now. even Microsoft ship pkgconf.

@ariadne the @debian.org should have been a clue. (Or see https://contributors.debian.org/ for anyone interested.)

@sertonix I think it would be good to enrich -static subpackages with the data, but .pc files need to continue staying in -dev packages.

@ariadne every maintainer can understand.

In #curl we started a yearly distro online meeting in 2024, to reduce obstacles about communication. Just knowing a name and maybe a face helps.

But it very much depends on the individuals. In another project, this works not so great. A distro guy telling me he decided to apply a patch and so I *must do this too* in the upstream. Yeah…

@ariadne I understand you're frustrated but I don't think anybody did anything wrong here.

Andrej made a major update to the pkgconf package and it broke stuff. The correct response is to revert the change, do a test rebuild outside the distro archive, fix all broken packages and then reintroduce the change, so no package build is ever broken.

In an optimal world, a test rebuild would have been done before the upload to unstable and any build failures fixed first.

@juliank this idea is also frustrating to me because I intend to officially make pkgconf 1.8 EOL.

I am far more frustrated by the fact that pkgconf is now co-maintained in Debian by someone who is assisting the u-config maintainers with their agenda of halting pkg-config development, who again, have spent the past 3 years harassing the pkgconf project with FUD and misinformation.

@icing @ariadne wait for real? How did they communicate it with you?

@mariop @ariadne Discussion on a github issue. Probably he did not mean it that way, but I was not happy nevertheless.

Too much going on for dwelling on this.

@ariadne were you even born then?

@ariadne I mean just declare it EOL, it's fine. As for the u-config packaging I wouldn't assume any nefarious intentions from the packager, he may not be aware of the history, but I can try following up on that once I'm back at an actual keyboard.

@tknarr, is it? Come on, do a better job.

@ariadne

@ariadne, you know, if this thread happened five years ago, I’d have orphaned pkgconf and never pushed for its adoption in Debian. THIS is how frustrated I am now.

@ariadne and of course they'll call it "2.5.1.really1.8.1" as they generally do, just to mess with people

(I think apt doesn't have version epochs, or something)

@andrew_shadura

look, i am sorry that we are both frustrated here. however, i am just boiling off steam. maybe it is a little impolite.

however, you know, from having worked together on audacious, that i am a very passionate and emotional person.

it is this passion that led to pkgconf being something you wanted to push for to begin with.

@grawity @ariadne a downgrade-unaware package manager in 2026, we love it

@ariadne That post now walks into conspiracy theory territory there. I know Andrej personally and I think you're assuming a lot more bad faith here than he deserves.

@andrew_shadura

please understand that while i do respect you and your work in general (and appreciate everything you have done to help improve the pkg-config mess by maintaining pkgconf in Debian), spending the past 2 years building an actually correct pkg-config solver just to have it broken again for distribution convenience is the sort of thing that really feels like a gut punch.

and that absolutely *is* bleeding onto here.

i too was traveling from FOSDEM when you first directed me to look at the Debian bug report. the reason why I told you to try with latest git is because we made some improvements to ensure that Requires.internal dependencies were always tolerated by the solver.

but if I had looked more carefully and noticed it was about Requires.private, I would have explained why the new solver is stricter.

the u-config thing when they first released it, was a major gut punch for me too, as has been the harassment from both u-config maintainers since then.

seeing that @tachi, who packaged u-config in Debian, was co-maintainer of pkgconf in Debian now brought up some old wounds.

for what it's worth I *am* willing to hear him out on that, but you have to understand from my perspective the dealing with the u-config people has been somewhat traumatic. i mean, in the main author's blog where he announced his project, he also just casually dropped a pkgconf 0day and made a snide comment about how we should be testing with ASan (which we do, as part of our CI, for the past almost decade). none of the other interactions since then have been more pleasant from either maintainer of u-config.

@highvoltage I know Andrej personally too, and you are right I am perhaps being more doomer than is deserved.

To be clear, I don't think anyone is actively conspiring here, just that sometimes the superpositions collapse in a way that is shitty.

@ariadne Yep, I don't know the full history either, but from the context I got in this thread, things sound fixable so I hope it goes into that direction from the Debian side so that it stops causing problems upstream and for users of the package in Debian.

@andrew_shadura

anyway, after taking a moment to process my thoughts, i decided to delete that thread dunking on debian. it isn't helpful for anyone toward solving the problem.

i'm sorry for expressing my frustration in that way, and i'm sorry for my frustration causing you frustration. truly, i owe you better than that.

i hope you can understand my skepticism about anything or anyone related to u-config though, given the context i provided. when the u-config author casually dropped a 0day in pkgconf just to shit on it... i had to scramble and do a security response days after I had finished moving cross-country because it was no longer safe for me to live where I was living due to being transgender. not great. anyway, i can't expect you to have that context.

i would prefer it we can find a path where Debian is not patching pkgconf to change the behavior of the solver. perhaps we can add a quirk that Debian can turn on (possibly via pkgconf-personality(5) files) to provide tolerations for missing Requires.private nodes when --static or --cflags are not requested.

but I think it is a really bad idea, it really would just be better to fix the -dev packages.

@andrew_shadura

anyway, @tachi -- it would be appreciated to understand some context on why you packaged u-config. what are you using it for?

in the initial ITP bug that I read, it was about --newlines, which I have already added to the next release.

I would like to find a path where we can implement whatever features u-config has that you find useful in pkgconf, so that u-config can be deprecated and removed from Debian.

my reason for wanting to deprecate it is due to the author's intent in maintaining u-config is not to actually help or improve the pkg-config ecosystem, but rather to halt progress in the pkg-config ecosystem. embracing u-config is bad for everyone who cares about pkg-config and wants to see us continue to build on the progress we've won over the past 15 years.

please: don't take my word for it, in his own blog where he casually drops 0day in both the original pkg-config and pkgconf to demonstrate how much of a better coder he is, he writes:

It doesn’t support every last pkg-config feature, nor will it ever. The goal is to support support existing pkg-config based builds, not make more of them. So, for example, features for debugging .pc files are omitted.

is this only about --newlines? is there something else you would like to see?

the ITP also notes that u-config does better with "malicious inputs." I do not really know what that means, but the CVE he dropped on his blog has long since been fixed in pkgconf, and he did not do proper disclosure of it. we also have been testing pkgconf with ASan in CI for the past 8 years.

we have also basically done a complete redesign of pkgconf's string/buffer management in the next release, building on work we started as part of pkgconf 2.x.

we are also planning to validate the correctness of pkgconf_buffer_t with CBMC (the C bounded model checker), a formal prover for C programs.

@ariadne @kimapr notably Guix is not using pkgconf

@noisytoot @kimapr I always keep forgetting about that. It is really a shame that is the case, as Guix would likely benefit significantly from adopting pkgconf.

For example, sdl3-compat depends on the Provides system to allow it to also claim sdl2.pc, which original pkg-config started to implement but never finished.

@andrew_shadura @ariadne Is it what?

I agree with the stricter solver behavior because I've seen bugs of the type reported in 1126924 before and the solution virtually always comes down to the one suggested by Guiseppe Bilotta.

Frankly just reverting an upstream commit like this to "fix" this sort of problem feels like a kludge to me, with chances of coming back to bite me being way too high for my liking. If it's a matter of principle, don't use that solver at all.