Collect meson wrapdb

[pombredanne]

See the repo at:

• https://github.com/mesonbuild/wrapdb/blob/master/subprojects/libnpupnp.wrap

This was pointed to me by @dcbaker ... it contains metadata for upstream C/C++ packages that are mostly pristine and are wrapper to subproject dependencies in meson.

• The doc is at https://mesonbuild.com/Wrap-dependency-system-manual.html
• .wrap files are config "ini" files defined at https://github.com/mesonbuild/mesonwrap/blob/c616627d7448fcadd601e838bedf1d717474cb1c/mesonwrap/ini.py#L75
• There is also an index files of sorts at https://github.com/mesonbuild/wrapdb/blob/master/releases.json

[pombredanne]

@dcbaker from a slightly deeper look, I think we likely need either a PURL type for the wrapdb, or a namespace in the future PURL registry https://github.com/package-url/purl-registry

Why? If I look at the files of some "wraps", like for ogg I have:

• the upstream version of 1.3.6
• the "release" version of 1.3.6-1 in https://github.com/mesonbuild/wrapdb/blob/9aeb67cda4af3b70caa155374271a56ad74f7ee5/releases.json#L3316
• a version "recipe" based on upstream 1.3.6 and defined in https://github.com/mesonbuild/wrapdb/blob/9aeb67cda4af3b70caa155374271a56ad74f7ee5/subprojects/packagefiles/ogg/meson.build#L4 itself likely based on upstream CMakeLists at https://gitlab.xiph.org/xiph/ogg/-/blob/main/CMakeLists.txt?ref_type=heads

Since 1.3.6-1 is a wrap-only thing, this like would require that we mint a PURL or namespace for that since these versions do not exist upstream, and may not always match exactly the default upstream config?

[dcbaker]

Ideally they would match exactly in behavior to whatever the upstream build system does, although outside of the simplest cases the ideal is probably unreachable. So ideally those -N prefixes don't represent changes to the binaries output, but changes to the Meson build definitions.

On the gripping hand, are there unique purls for projects that provide two build systems based on the build system used? I can think of something that I work with like Waffle, which has two upstream build systems. Ideally those do the same thing, but the the reality is that they probably do result in slightly different code, or some discussions in regards to Nlohmann JSON that the CMake export target and the pkg-config behave differently because the CMake export target prebakes certain options through a generator expression that are difficult to describe in pkg-config, would those also need different purls?