Does this package need a run_export?

[hmaarrfk]

Comment:

Thank you the advise.

[pkgw]

I think maybe the current setup has what it needs? The libgirepository package doesn't have a run-export setting, but the g-ir-host-tools package has a run requirement on libgirepository, as does the gobject-introspection metapackage. Packages that are building with the gobject-introspection system will be depending on the host-tools subpackage in their host build, so that should introduce the dependency on the shared library at runtime. ... I think? Is there a specific issue that prompted this question?

[hmaarrfk]

I'm not sure that totally works. Users will have to manually add libgirepository to their run requirements.

The run_export guarantees that any addition to a host requirement is reflected as the appropriate runtime requirement (with correct pinnings).

[pkgw]

Well, I don't see any harm in adding a run-export in the libgirepository subpackage spec. Do you think that'd cover things?

[hmaarrfk]

Can you show me an example of a package that uses this feedstock with cross compilation. I'm having a hard time with it for libvips. It can help me answer your question better.

[pkgw]

pango does. So does poppler. Based on my grepping and searching it looks like most of our feedstocks just depend on the gobject-introspection kitchen-sink package and not the specific g-ir-* ones, so some of the run-exports might not be set up right.

[hmaarrfk]

It seems that there are 2 use cases:

1. the gobject introspection build tools as tools
2. The library.

Looking through the logs of pango and poppler, it seems that they only use the tools, and not the dynamic library at runtime.

libvips on the otherhand seems to need the library. It may be that libgirepository needs to run_export itself.

[pkgw]

Hmm, yeah, if a package is providing binding data so that scripting languages can interact with it, I don't think it should need the library at runtime. That should only come in if a package is actually loading bindings and interacting with them. But regardless of all that, I have trouble seeing how a run_export in libgirepository would be wrong.

[ryanvolz]

Hmm, yeah, if a package is providing binding data so that scripting languages can interact with it, I don't think it should need the library at runtime. That should only come in if a package is actually loading bindings and interacting with them. But regardless of all that, I have trouble seeing how a run_export in libgirepository would be wrong.

I agree, it seems correct that a package building against libgirepository surgically would benefit from a run_export. I just don't think we've encountered such a package until now.

[hmaarrfk]

Yeah I was kinda wondering the same about why it wasn't an error before. I just don't think anybody actually linked against libgirepository, the two packageds mentioned by pkgw don't list it as being used.