Install into architecture specific directory by default

[plicease]

This would allow the same lib directory to be shared in a non-homogeneous network environment (see #118 for related discussion). I have worked in these environments in the past, it is particularly useful with AFS.

Looking closely at the Module::Build and ExtUtils::Install source, the only way to force an install into the arch directory is if the blib/arch directory is not empty, so I propose putting a .txt file in there with the name of the module with a comment explaining its existence.

@jberger mentioned Mach as being an exception where you might want to install into a non-arch specific directory in a non-homogeneous environment. The only example where mach is typically used with Perl that I could think of is OS X where the arch is the same for intel, ppc, 32 and 64 bit platforms, so even if Perl is a universal binary then thing should still work (things are not so good if you need to support multiple non-universal Perl binaries, but that is a problem for non-arch install as well).

One place I can think of where installing into the non-arch directory makes sense is for Linux distribution integrator who probably only want one Alien::Foo package, not one for each arch (assuming they package them correctly to use the system library), so I've provided them with an out. If they set ALIEN_ARCH=0 this will override the default value for alien_arch.

I'd be interested in any other corner cases that anyone can think of.

[plicease]

@mohawk2 @zmughal I'd appreciate your input on this. @jberger expressed in #118 that he didn't see the point. I respectfully disagree: I find the current behavior of AB to be inconsistent with other installer tools, and further actively makes unworkable certain network environments (especially AFS with non-homogeneous nodes).

Two places where I think you might want to turn this off:

• When you are creating distribution packages (.dep and .rpm files) that are explicitly configured to use the system libraries, and you want to keep perl-Alien-Foo or libalien-foo-perl to be noarch packages. I feel I have addressed this with the ALIEN_ARCH environment variable which can be specified in a rpm .spec file or .deb equivalent.
• When installing non-arch specific packages, JavaScript or CSS or what have you. This is addressed by having an alien_arch property, which overrides the ALIEN_ARCH environment variable.

If there is strong feeling against this proposal, I would at least like to have this available as an option for system administrators (via the ALIEN_ARCH environment variable) but have the default be off. This is not my preference.

[jberger]

I suppose that as long as it work AND as long as it is still scoped to your
currently running perl interpreter paths (which is really the only
overarching (heh) design principal I have been following) I should defer to
you. You seem to have a stronger grasp of the benefits and I really can't
come up with a case against other than complexity.

On Fri, May 1, 2015 at 3:16 PM Graham Ollis notifications@github.com
wrote:

@mohawk2 https://github.com/mohawk2 @zmughal
https://github.com/zmughal I'd appreciate your input on this. @jberger
https://github.com/jberger expressed in #118
#118 that he didn't see
the point. I respectfully disagree: I find the current behavior of AB to be
inconsistent with other installer tools, and further actively makes
unworkable certain network environments (especially AFS with
non-homogeneous nodes).

Two places where I think you might want to turn this off:

• When you are creating distribution packages (.dep and .rpm files)
  that are explicitly configured to use the system libraries, and you want to
  keep perl-Alien-Foo or libalien-foo-perl to be noarch packages. I feel
  I have addressed this with the ALIEN_ARCH environment variable which
  can be specified in a rpm .spec file or .deb equivalent.
  • When installing non-arch specific packages, JavaScript or CSS or
    what have you. This is addressed by having an alien_arch property,
    which overrides the ALIEN_ARCH environment variable.

If there is strong feeling against this proposal, I would at least like
to have this available as an option for system administrators (via the
ALIEN_ARCH environment variable) but have the default be off. This is not
my preference.

—
Reply to this email directly or view it on GitHub
#119 (comment)
.

[mohawk2]

A compiled library is arch-specific and should be installed as such; not doing so will lead to breakage for a Perl installation that is shared among multiple architectures. I respectfully disagree with @jberger in the same way as @plicease.

[zmughal]

I'm on the fence about this. I'm leaning towards including it since it doesn't add too much complexity. I just haven't had to deal with multiple architecture systems.

[plicease]

@zmughal would you be happier if this was not on by default? My preference is to include the feature and have it on by default, as I mentioned I feel it is more consistent and it does better support non-homogeneous environments. However it would be sufficient to make it an option and integrators who require this can set ALIEN_ARCH when they build their packages. Also if there were a lot of people clamoring to make it the default and we change our mind, then it is easier to make turn if on by default than to try and turn it off by default (the arch directory appears in @INC before the pure perl directories).

[zmughal]

@plicease, I would be happy if it wasn't the default at first because as you said, it would be easier to change the default from off to on later. Otherwise I am fine with the change and say

Merge: Aye

[plicease]

Merging with the default set to off. I will do a dev release. I don't think there is a big hurry in making a prod release for just this.