libxmlpp wrap name doesn't equal pkgconf file name

[ntonnaett]

I just discovered that there's a libxml++ wrap called libxmlpp. I thought the wrap name should equal the pkgconf file. The libxmlpp wrap is outdated. I'm wondering if this wrap should be updated or if I should create a new one with the "right" name.

libxml++ has another problem. There are three different versions that are not distinguished by their pkgconf name (like with gtk for example). Should this be fixed first upstream? Should the naming of the wraps (and pkgconf file) be libxml++-3 then?

[ntonnaett]

My fault… the naming is already libxml++-3.0.

[xclaesse]

Hum, that's unfortunate indeed. Renaming the wrap is not really important, but I see we don't generate a pkg-config file and the libxmlpp.wrap should have a [provide] section with the right name.

[ntonnaett]

If there's just one wrap for all versions, I need a hidden variable, right? That's like using cmake…

[ntonnaett]

Upstream doesn't need to be patched anymore. It should generate a pkg-config file.

[eli-schwartz]

libxml++ has another problem. There are three different versions that are not distinguished by their pkgconf name (like with gtk for example). Should this be fixed first upstream? Should the naming of the wraps (and pkgconf file) be libxml++-3 then?

Many upstreams consider this a feature, not a bug. Many consider this a bug, not a feature.

The WrapDB isn't inherently opinionated on the subject, it simply attempts to implement the upstream interface. If upstream versions their pkg-config file, then wrapping it here means versioning the dependency name. If not, then versioning the dependency name is a bug, of the "doesn't conform to upstream" style.

If there's just one wrap for all versions, I need a hidden variable, right? That's like using cmake…

A hidden variable for what? There's only one wrap for one version, but there are different versions of a wrap. If the wrap contains the version in its name and internal paths, such as with gtk3/gtk4, then it's viable to have them in parallel, although you probably shouldn't use both in one project.

It's always possible to manually use old versions of a wrap. You cannot download them via meson wrap install, but they are there in the web interface.

[ntonnaett]

Okay. Then there should be three wraps called libxml++-3.0, libxml++-4.0 and libxml++-5.0.

[eli-schwartz]

Why?

I understand why the pkg-config dependency names should be like that, but what's the specific use case of having old wrapped versions?

[ntonnaett]

2.6 is old. 3.0, 4.0 and 5.0 are the current ABIs. These are just flavours.

[eli-schwartz]

repeating the initial premise doesn't answer the question: what's the practical use case here?

[ntonnaett]

I'm not the developer of libxml++. So I can't answer why somebody wants to maintain three different ABIs of the same library. It looks like the difference is just their dependencies. 3.0 depends on glibmm-2.4. 4.0 depends on glibmm-2.68. 5.0 doesn't depend on glibmm but has worse UTF-8 support.

https://libxmlplusplus.github.io/libxmlplusplus/

[talisein]

A gtkmm3 app need to use -3.0, gtkmm4 apps need to use -4.0, and non-gtk apps would use -5.0. So a gtk3 apps' dependency('libxml++-3.0', fallback: ['libxmlpp']) -- which is a legitimate intention -- will fail with the -5.0 wrap since its not providing -3.0. If you download libxmlpp_3.0.1-2's wrap from the wrapdb website, that lacks the [provides] magic but you can dependency('libxml++-3.0', fallback: ['libxmlpp', 'libxmlpp_dep']). gtk4 apps can't use the wrapdb at all, but could just use upstream.

The current situation is manageable (particularly since upstream uses meson now) so I don't want to volunteer work for anyone, but I hope my comment explains why having the 3 abi's available would make sense.