Quoting rules differs to pkg-config -> update breakage #111

New Issue

ariadne · 2017-02-03T14:39:35Z

ignatenkobrain commented

2017-02-03 14:39:35 +00:00

(Migrated from github.com)

From: https://bugzilla.redhat.com/show_bug.cgi?id=1419054

Version-Release number of selected component (if applicable):

pkgconf-1.2.1-1.fc26.x86_64

Actual results:

# pkg-config --cflags  lirc-driver
-fpic -DPLUGINDOCS="/usr/share/doc/lirc/plugindocs"

Expected results:

As in f25 (pkgconfig-0.29.1-1):

# pkg-config --cflags  lirc-driver
-fpic -DPLUGINDOCS=\"/usr/share/doc/lirc/plugindocs\"

Additional info:

Obviously, pkg-conf doesn't parse the lirc-driver.pc the same way as pkg-config. Relevant parts of this below, note how PLUGINDOCS is quoted.

Name: lirc

PACKAGE_TARNAME=lirc
prefix=/usr
docdir=${prefix}/share/doc/${PACKAGE_TARNAME}

Cflags: -I${includedir} -fpic -DPLUGINDOCS='"${docdir}/plugindocs"'

From: https://bugzilla.redhat.com/show_bug.cgi?id=1419054 # Version-Release number of selected component (if applicable): pkgconf-1.2.1-1.fc26.x86_64 # Actual results: ``` # pkg-config --cflags lirc-driver -fpic -DPLUGINDOCS="/usr/share/doc/lirc/plugindocs" ``` # Expected results: As in f25 (pkgconfig-0.29.1-1): ``` # pkg-config --cflags lirc-driver -fpic -DPLUGINDOCS=\"/usr/share/doc/lirc/plugindocs\" ``` # Additional info: Obviously, pkg-conf doesn't parse the lirc-driver.pc the same way as pkg-config. Relevant parts of this below, note how PLUGINDOCS is quoted. ``` Name: lirc PACKAGE_TARNAME=lirc prefix=/usr docdir=${prefix}/share/doc/${PACKAGE_TARNAME} Cflags: -I${includedir} -fpic -DPLUGINDOCS='"${docdir}/plugindocs"' ```

leamas commented

2017-02-03 14:54:28 +00:00

(Migrated from github.com)

I filed the fedora bug; watching this github issue.

ariadne commented

2017-02-03 18:33:05 +00:00

I think both pkgconf and pkg-config output is wrong given the cflags. In reality, pkg-config output is more wrong as the plugindocs is quoted already.

It should be rendering it as -DPLUGINDOCS='"/usr/share/doc/lirc/plugindocs"'.

Thoughts?

I think both `pkgconf` and `pkg-config` output is wrong given the cflags. In reality, pkg-config output is more wrong as the plugindocs is quoted already. It should be rendering it as `-DPLUGINDOCS='"/usr/share/doc/lirc/plugindocs"'`. Thoughts?

leamas commented

2017-02-03 18:44:57 +00:00

(Migrated from github.com)

I cannot see that '"foo' is better than \"foo\", or that pkgconfig is broken. It works, it's not just insane, and there is no spec.

What happens here is that the outer, single quotes are removed and the rest is saved internally, including the literal double quotes. Later, when written, the problem is how to represent the literal double quotes. As long as it works, it should be OK, be it \" or '"' .

However, when selecting which form to use, using the pkgconfig style might be better for compatibilty reasons. It might also be easier to avoid matching quotes internally by just replacing the literal " with \" on output.

But any way, I cannot see it's big deal as long as it works.

I cannot see that *'"foo*' is better than \\"foo\\\", or that pkgconfig is broken. It works, it's not just insane, and there is no spec. What happens here is that the outer, single quotes are removed and the rest is saved internally, including the literal double quotes. Later, when written, the problem is how to represent the literal double quotes. As long as it works, it should be OK, be it \\" or '"' . However, when selecting which form to use, using the pkgconfig style might be better for compatibilty reasons. It might also be easier to avoid matching quotes internally by just replacing the literal " with \\" on output. But any way, I cannot see it's big deal as long as it works.

ariadne commented

2017-02-03 18:48:31 +00:00

The escaped version is worse for us because libpkgconf consumers would need to process the fragments to unescape them.

ariadne commented

2017-02-03 18:50:57 +00:00

Seems the problem is in pkgconf_argv_split().

leamas commented

2017-02-03 18:51:29 +00:00

(Migrated from github.com)

Hm... I cannot see that a library call should give the same output as the command line pkg-config call. Shouldn't the library call just return "foo", no secaping, and the pkg.config CLI command then adds escaping as required?

ariadne commented

2017-02-03 19:00:48 +00:00

That is usually the case. In this case, there was quoting being removed and that is the actual problem -- extra quoting would not be needed on the CLI if we were not messing up the fragment to begin with.

ariadne commented

2017-02-03 19:04:35 +00:00

These fixes will be in pkgconf 1.2.2. Thanks to everyone involved for reporting this edge case.

leamas commented

2017-02-03 19:10:05 +00:00

(Migrated from github.com)

Hm... if this means that the library call returns ' "foo" ' I doubt this is sane. That said, my specific use-case will work, though.

ariadne commented

2017-02-03 19:33:44 +00:00

In this case, it will return the same output as the CLI, which is what we want, as it matches what is in the original .pc file.

A difference between pkgconf and pkg-config in general is that we try to assume that the .pc is correct and therefore try to avoid modifying the data inside it at all, unless absolutely necessary.

Thanks again for reporting!

In this case, it will return the same output as the CLI, which is what we want, as it matches what is in the original .pc file. A difference between pkgconf and pkg-config in general is that we try to assume that the .pc is correct and therefore try to avoid modifying the data inside it at all, unless absolutely necessary. Thanks again for reporting!

leamas commented

2017-02-03 19:52:26 +00:00

(Migrated from github.com)

Well, the problem is that if you try to replicate the pkg-conifg semantics it might be wrong. I understand teh situation as pkg-config mimicking the shell, removing the outer quoting. In my case, the outer quoting is not part pf the actual definition, it's just there to make the double quotes literal

If I request this data from pkg-config and get ' "foo" ' it's all fine. However, if I requested the same data from a library call I would actually expect "foo", no single quotes i. e.,the actual value. It's not any actual problem for me though, it's just FYI

Well, the problem is that if you try to replicate the pkg-conifg semantics it might be wrong. I understand teh situation as pkg-config mimicking the shell, removing the outer quoting. In my case, the outer quoting is not part pf the actual definition, it's just there to make the double quotes literal If I request this data from pkg-config and get ' "foo" ' it's all fine. However, if I requested the same data from a library call I would actually expect "foo", no single quotes i. e.,the actual value. It's not any actual problem for me though, it's just FYI

Sign in to join this conversation.