Alien::Sodium not always necessary (and at times unhelpful)

[leonerd]

I've been trying to build a debian package of this distribution. For long and complex reasons, anything derived from Alien::Base is more awkward here than I'd like. Instead of building libsodium via that method, I've gone and built a native debian package for it.

I then applied a relatively small hack to your Makefile.PL to avoid the use of Alien::Sodium and instead use ExtUtils::PkgConfig directly. This patch is currently applied as part of my debian package.

[leonerd]

My patch (since github doesn't let me attach a .patch file directly): https://github.com/leonerd/crypt-nacl-sodium/commit/4625263559cd304ee49e32113e20bec2688c90bc

I don't imagine upstream wants to apply this change as-is, because it would be unhelpful in those cases where pkg-config can't find the library, or it really isn't installed. But perhaps some hybrid approach of the two could be applied?

[ajgb]

Hi,

The reason for using the Alien::Sodium is that I'm able to provide the latest version of the library, rather then relay on the package provided by given distribution - as the functionality of the module itself does require the latest version of libsodium.

So while I'm aware of the problems with Alien::Sodium (did run in several smoke tests failures, but that seems to be resolved now) I'm afraid cannot apply that change.

Thank you, Alex

[leonerd]

Isn't this what::

ExtUtils::PkgConfig->atleast_version("libsodium", "1.0.3") or
  die "OS unsupported - libsodium is too old; need at least 1.0.3\n";

is for?

[ajgb]

Sure, but that was not in your patch and it only resolves half of the problem - the requirement of certain version of libsodium available.

And your patch also removes the dependency on Alien::Sodium so the poor user is left with only one option - manually install the library.

Could you tell me what are the packaging problems related to Alien::Base that you are trying to avoid?

[leonerd]

As I said in my comment, you almost certainly /don't/ want to apply it as-is. Likely you want to merge some sort of hybrid out of it; either detect dynamically, or just take a commandline argument to the Makefile.PL itself so a debian package can just say "trust me, we have a system-level version, you don't need the Alien"

[ajgb]

I really appreciate the concept, but I just don't think that this is the right solution.

If what you are trying to do is to provide this module as .deb package, and running cpanm Crypt::NaCl::Sodium is not acceptable, why not create two packages: libalien-sodium-perl and libcrypt-nacl-sodium-perl with latter depending on the former?

[shadowcat-mst]

Basically, Alien::Sodium is a significant chunk of extra 'stuff' that's completely unneeded in this case.

What about a Makefile.PL option or env var to say "look, I know what I'm doing, go the ExtUtils::PkgConfig route"? That way everybody else gets the Alien:: route but people who specifically want to do things this way can set up their .deb (or whatever) build script to tell your code to do things that way?

[leonerd]

That approach could work in the general case of Alien packages (and is how I do several of my own Aliens). But my way of doing Aliens is a lot less hostile to Debianisation.

Namely, if the platform does already provide the actual library in a way that pkg-config can find it, I simply act as a minimal passthrough to that. The upshot here is that if the debian package build-requires the underlying C library's -dev package and the libalien-foo-perl package, then the resultant binary package can depend directly on the lower-level C library, and the target system does not need the Alien perl library installed at all.

The way that Alien::Base works means that this cannot happen, and thus the target needs to have Alien::Base plus all its dependency tree installed. On top of this, the built libalien-sodium-perl package would carry with it its own copy of the libsodium.so file, independent of the real one installed on the target machine.

[leonerd]

Ahyes - an env. var or commandline argument or such would be fine for me. Since building the debian package is under full control of how it runs perl Makefile.PL in the first place, it can easily pass along that extra option.

[ajgb]

To be honest I don't like the creation of deb/rpm packages out of Perl modules and tracking the dependencies at another level, but I understand that you may not be in the position to get around that, so I've added following switches to Makefile.PL:

• -L /path/to/lib/dir/ (this is where libsodium.a is expected)
• -I /path/to/include/dir (where sodium.h is expected)

On jessie, the invocation could look like this: perl Makefile.PL -L /usr/lib/x86_64-linux-gnu/ -I /usr/include/

I've kept the dependency on Alien::Sodium, as I think that it is a special case anyway.

That has been just released as version 0.07

[plicease]

@leonerd Alien::Sodium is not (was not) does not have to be a run-time dep of Crypt::NaCL::Sodium, since it was linking against a static lib. In fact any Alien::Base Alien that uses alien_isolate_dynamic should not be a run-time dep. I'm interested in making Alien::Base more friendly to system integrators. Perhaps if you could let me know what particular problems you are having we can help you address them in AB, rather than you needing to patch each Perl distribution that uses it. Making sure AB is not a run-time dep is just one of the things that I have done in order to try and make it easier on system integrators, while at the same time keep it simple for people installing directly out of CPAN.

edit on closer inspection it could be a run-time dep if a source build is done, but definitely does not have to be and definitely should not be.

[plicease]

Also related are these patches:

https://github.com/ajgb/alien-sodium/pull/1 https://github.com/ajgb/crypt-nacl-sodium/pull/2

Which will allow building Crypt::NaCL::Sodium from the system library without needing any magic flags when building Crypt::NaCl::Sodium.