Graham Ollis

Last week I promised (or threatened depending on your outlook) to talk about Alien::Base in the context of system integration and distribution packagers.

Philosophy:

The philosophy for Alien::Base has always been that the system library should be used when it is available, and if not, the source code for that library can be downloaded and installed for you. My own Alien::FFI (isa Alien::Base) which provides libffi, and FFI::Platypus which uses it is a good example of the success of this approach as you can see from their respective testing matrices.

Alien::Base is of course trying to keep everyone happy all of the time, and everyone knows that is impossible. System vendors complain that Alien::Base has too many dependencies. Module authors fear that using the system library will make it too hard to support their XS modules since they could end up linking against almost anything. These perspectives frequently clash and it can be a challenge to maintain empathy for other parties when they do.

Yes, Alien::Base has a number of non-core dependencies that don’t do much when you simply end up using the system library. On the other hand, many of them, such as Capture::Tiny and URI are useful in their own right. In addition once you’ve gone through the pain of providing a package for Alien::Base and its dependencies you can use it again for other Alien::Base based distributions and the XS modules that use them without having to bug their maintainers with patches. If something in Alien::Base doesn’t quite work with your build system, please notify us right away so that we can fix it! We don’t hate you. We just work in a different environment that you and may be unaware of your pain. As an example, we added support for destdir (commonly used when creating Linux binary packages) back in version 0.005. I take responsibility for unintentionally breaking that in version 0.017, since we didn’t have a test for destdir installs. Thanks to feedback we’ve fixed that and added a test that will make sure that it doesn’t happen again.

Yes, depending on the system library does have its challenges, and it makes me personally uneasy to think about all the ways that something could go wrong. On the other hand there are also benefits to using the system library, as they are usually optimized for the particular environment and will more likely to have security patches applied. It is also good to keep in mind that nobody is asking you to support the system library. That is the responsibility of the system developer. I do ask that you not actively stand in the way of people who DO want to support the system library. If there are known bad versions, there is a way to specify a minimum or specific library version, which should be good enough in most situations.

Fundamentally, it’s good to assume good faith, until you can prove otherwise. Remember that for a CPAN author using Alien::Base makes developing and maintaining Alien distributions easier. Remember that for a system vendor, being able to maintain just one version of a library saves time and reduces bugs.

Technical:

The rest of this entry includes some technical notes that may be useful for system vendors, and those that are really interested in Alien.

I mentioned that destdir support was broken in 0.017 (it was fixed again in 0.022). Ironically in most cases you will actually not want to take advantage of this feature, since it is only required when building the library from source, rather than using the system library. In the next version of Alien::Base I hope to have an interface to make it fail when the system library cannot be detected. This is usually what system vendors who provide the library as a separate package will want. If you want to have some say in how this interface is exposed, now is an excellent time to make yourself heard:

https://github.com/Perl5-Alien/Alien-Base/pull/135

Alien::Base based modules should almost never be a run-time prerequisite with newer versions of Alien::Base, so long as they use the alien_isoloate_dynamic option. This is highly recommended as long as your package can be built as a static library, which is almost always what you want when you are building an Alien package from source for XS.

Disclaimer: the remainder of this entry represents my opinions only, and not those of the Alien::Base team. This is true for everything that I write here, but in particular my last two points should be considered either unsettled or controversial.

Perl usually has paths for architecture specific and platform independent module files. Alien::Base does not install into the architecture specific directory by default, even though in most cases it does install architecture specific files. I am not entirely sure that I agree this is right, but we weren’t able to achieve consensus on changing it. There is now an option and an environment variable to change this behavior. The reason you might want to install into the architecture specific path is if you are installing to a non-homogeneous environment such as AFS. Another use case would be if you were creating a system package for for a library that isn’t otherwise provided by your operating system, and will thus be built by the Alien::Base system from source.

Finally, I feel there is some room for slimming the dependencies on Alien::Base if people make the case. If there are some prereqs that seem unreasonable, please open a ticket on the project GitHub (I can’t guarantee that you won’t be the one to do the actual work so be careful what you wish for). As an example, now that Archive::Extract has been removed from the core, it might be worth investigating switching to Archive::Tar (still in the core) which should work in most cases and pulling in Archive::Zip only when it is needed, which should cover virtually all other cases. The dependency on Module::Build (MB) is probably not too popular amongst its MB detractors. At the moment I don’t see a good alternative, but I have some ideas on how to proceed if this is important to you.