System-type installation without storing datails about the library

[ppisar]

System-type installation stores a library-specific data into a JSON document at build-time. The data are then returned at run-time. An example:

cat /usr/lib64/perl5/vendor_perl/auto/share/dist/Alien-Libxml2/_alien/alien.json
{
   "alien_build_version" : "2.70",
   "cflags" : "-I/usr/include/libxml2",
   "cflags_static" : "-I/usr/include/libxml2",
   "install_type" : "system",
   "legacy" : {
      "finished_installing" : 1,
      "install_type" : "system",
      "original_prefix" : "/usr/lib64/perl5/vendor_perl/auto/share/dist/Alien-Libxml2",
      "version" : "2.9.14"
   },
   "libs" : "-lxml2 -lz -llzma -lm",
   "libs_static" : "-lxml2 -lz -llzma -lm",
   "perl_module_version" : "0.19",
   "prefix" : "/usr/lib64/perl5/vendor_perl/auto/share/dist/Alien-Libxml2",
   "version" : "2.9.14"
}

My problem is that the data become invalid when the system library is updated or downgraded. Usually the version stops matching. (But it could be linker flags or any other ones.)

I package the Perl modules into RPM packages and I work around it by adding an RPM-level dependency on an exact library version into the Alien package. That way users need to update both the library and the Alien RPM package. This saves users, but creates headaches to package maintainers who need to rebuild Alien package whenever the library is rebased. However, this is a general problem not specific to RPM distributions.

Would it be possible to change Alien in a way in which system installations do to not store the data and instead retrieve them at run-time? Effectively rerunning the installed alienfile at run-time. At the end, all the data can be retrieved with pkg-config. Duplicating them doesn't seem the right way.

[plicease]

Possibly, at least on an opt-in basis. We avoid re-running the alienfile at "runtime" because it brings in a lot of extra dependencies into your runtime process. This would primarily be a problem with FFI which if it uses an Alien it will use it at real runtime, but for XS "runtime" is usually actually build time for the XS module.

[ppisar]

Thanks for the information. I have a related question: Now the alienfile is installed as _alien/alienfile. Is that file used for anything after the installation (in either system and shared modes of installation)?

[plicease]

Yes in either share or system install _alien/alienfile can be used to reinstall the alienized package without going through a cpan client or re-installing the Alien dist. This could be to switch from share or system install, or it could be used to upgrade a share install. In principal anything with write access to the share directory could do this, but in practice (so far) App::af is the only tool that does this.

[plicease]

It can also be a useful reference to the exact recipe that was used to do the install.