pkg -e generates incorrect expanded manifest

[danfe]

When packages are created with expanded manifest (-e option), the resulting manifest file is broken, because it is not correct JSON.

[bapt]

the manifest is not supposed to be json at all

[danfe]

Then pkg(8) should handle it better. Try generating package with a license which includes the plus sign, e.g. archivers/gzip, and install it. I'll getting this:

# pkg add <wrkdir>/pkg/gzip-1.10.txz 
pkg: Error parsing manifest: error while parsing <unknown>: line: 41, column: 45 - 'invalid character in a key', character: '+'
pkg: /tmp/usr/ports/archivers/gzip/work/pkg/gzip-1.10.txz is not a valid package: Invalid manifest
# pkg -v
1.16.1

[bapt]

pkg should handle what better ? I don't understand what you are trying to do, the +MANIFEST is a ucl file, as long as the ucl file is valid the manifest will be parsed correctly

[danfe]

So if you make package in archivers/gzip with -e added to the PKG_CREATE_ARGS and then can add it via pkg add without issues?

[bapt]

yes I can do that as long as I use a UCL valid syntax

[danfe]

Hm, that's strange. What is the checksum of generated +MANIFEST for archivers/gzip port on your machine with -e?

as long as I use a UCL valid syntax

No, no, we don't deal with UCL directly at all, it's about calling make PKG_CREATE_ARGS='-e -r ${STAGEDIR}' package and result it produces.

[bapt]

ok I misunderstood the bug, now I got it and I can reproduce

[bapt]

@vstakhov sounds like a bug in libucl which I can easily reproduce:
echo '"a+" = b' | ./utils/ucl_tool | ./utils/ucl_tool

The first call is generating a UCL output which cannot then be parsed again by the second one

[vstakhov]

Indeed,

LuaJIT 2.1.0-beta3> p:parse_string('"a+" = b')
true
LuaJIT 2.1.0-beta3> p:get_object()
{[a+] = b}
LuaJIT 2.1.0-beta3> u.to_format(p:get_object(), 'ucl')
a+ = "b";

LuaJIT 2.1.0-beta3> p:parse_string(u.to_format(p:get_object(), 'ucl'))
false
error while parsing <unknown>: line: 1, column: 0 - 'delimiter is missing', character: 'a'

UCL should escape '+' character in this case (and the whole key in fact). JSON works fine in this case.