maximum_package_count is off by one when limiting number of packages to consider

[jashank]

Hello!

Scenario: I have packages atf-c, atf-c++, atf-sh. (Any set of two or more packages works for this trick; I happen to have these three from the same source alphabetically early in my list of packages.)

$ pkgconf --modversion atf-c atf-c++ atf-sh
0.20
0.20

... so where did the third one go?

Spelunking the code, I see that --modversion (and some other flags) put us into a mode where we only consider one package at a time by setting maximum_package_count — perfectly reasonable (though I don't know if this behaviour is actually documented anywhere except here in the source, so surprising in that regard):

pkgconf/cli/main.c

Lines 1113 to 1127 in 78f3abc

	/* if these selectors are used, it means that we are inquiring about a single package.
	* so signal to libpkgconf that we do not want to use the dependency resolver for more than one level,
	* and also limit the SAT problem to a single package.
	*/
	if (((want_flags & PKG_REQUIRES) == PKG_REQUIRES ||
	(want_flags & PKG_REQUIRES_PRIVATE) == PKG_REQUIRES_PRIVATE ||
	(want_flags & PKG_PROVIDES) == PKG_PROVIDES ||
	(want_flags & PKG_VARIABLES) == PKG_VARIABLES ||
	(want_flags & PKG_MODVERSION) == PKG_MODVERSION ||
	(want_flags & PKG_PATH) == PKG_PATH ||
	want_variable != NULL))
	{
	maximum_package_count = 1;
	maximum_traverse_depth = 1;
	}

However, the logic to actually enforce this erroneously compares cardinal pkgq.length to ordinal maximum_package_count:

pkgconf/cli/main.c

Lines 1324 to 1328 in 78f3abc

	/* check if there is a limit to the number of packages allowed to be included, if so and we have hit
	* the limit, stop adding packages to the queue.
	*/
	if (maximum_package_count > 0 && pkgq.length > maximum_package_count)
	break;

(I stumbled across this bug because Cabal does this wrong then fails for mysterious reasons; I'll also file a bug there about this behaviour.)

[kaniini]

Fixed in pending 1.9.5 release. Thanks!

[Dretch]

I wonder if you would consider making pkgconf fail (with a non-zero exit code) when given multiple packages (e.g. pkgconf --modversion atf-c atf-c++ atf-sh).

Some motivation for this:

• It would make pkgconf-provided pkg-config does --modversion differently; dependency resolution fails mysteriously haskell/cabal#8923 less of a problem: there is an existing fallback code path in cabal that calls pkgconf --modversion <pkg> for each <pkg> if the invocation with all the packages at once fails.
• The command line with multiple packages is incorrect, so the user should be told about it.

[juhp]

I also stumbled across this today (initially with 1.9.4) and also in the context of Haskell cabal.
But I don't think it was "off-by-one": 1.9.4 never printed more than two versions for me!

And 1.9.5 only ever seems to print one version for me:

$ pkgconf --version
1.9.5
$ pkgconf --modversion pango glib-2.0 gio-2.0 harfbuzz 
1.50.14
$ 

Anyway I can open a new issue, since this is closed, though not fixed afaict - re-opening would also make sense.

[juhp]

Ah wait you are saying that outputting one package version now is the correct behavior I see...
Then haskell Cabal needs to be fixed...

And +1 for erroring for more than one package