Bug #122236 for ExtUtils-MakeMaker: EUMM: Partial INSTALLVENDOR* override results in non-arch INSTALLVENDORARCH

Mon Jun 26 08:37:36 2017 al.dunsmuir [...] sympatico.ca - Ticket created

Subject:	EUMM: Partial INSTALLVENDOR* override results in non-arch INSTALLVENDORARCH
Date:	Mon, 26 Jun 2017 08:33:55 -0400
To:	bug-ExtUtils-MakeMaker [...] rt.cpan.org
From:	Al Dunsmuir <al.dunsmuir [...] sympatico.ca>

I've tracked down a build problem building all vendor arch files on AIX in the following ticket. It was suggested I open another here. #131559: ExtUtils::Command::MM not installing files in vendor arch-specific directories https://rt.perl.org/Ticket/Display.html?id=131559 I've got over 300 AIX-specific perl rpm packages that I'm trying to build with 5.26.0 (updated to EU:MM 7.30 with the AIX test fix). The non-arch builds worked fine, but all all arch-specific builds failed because the arch-specific files were being installed into non-arch directoryies. My original RPM .spec file recipe was: %{__perl} Makefile.PL INSTALLDIRS=vendor \ INSTALLVENDORLIB=%{perl_vendorlib} INSTALLVENDORMAN3DIR=%{_mandir}/man3 \ NO_PACKLIST=1 OPTIMIZE="%{optflags}" I changed this to: %{__perl} Makefile.PL INSTALLDIRS=vendor \ INSTALLVENDORLIB=%{perl_vendorlib} INSTALLVENDORARCH=%{perl_vendorarch} \ INSTALLVENDORMAN3DIR=%{_mandir}/man3 \ NO_PACKLIST=1 OPTIMIZE="%{optflags}" and the build was successful It appears that overriding INSTALLVENDORLIB without also overriding INSTALLVENDORARCH caused the INSTALLVENDORARCH value to be corrupted. I tried the minimalistic version: %{__perl} Makefile.PL INSTALLDIRS=vendor NO_PACKLIST=1 OPTIMIZE="%{optflags}" and that also worked. So it appears that the EU:MM handling of just INSTALLVENDORLIB results in an invalid INSTALLVENDORARCH value. These overrides were from a few perl RPM builds back to 5.8.8 days and were simply propagated across all the new pagkages. Since I'm doing a full rebase to 5.26.0 anyway, I will remove them from all my .spec file recipes. That solves my immediate problem, but EU:MM should be corrected in this area. -- Al Dunsmuir

Tue Jun 27 22:38:37 2017 ETJ [...] cpan.org - Correspondence added

Hi Al, Thanks for this report. The behaviour you describe as a "corrupt" value is apparently a deliberate choice as implemented in init_lib2arch at https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/blob/master/lib/ExtUtils/MM_Unix.pm#L1926 - to use the VENDORLIB for "arch" files if no VENDORARCH supplied. I have made a PR which updates the documentation and welcome your thoughts: https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/pull/306/files Best regards, Ed

Tue Jun 27 22:38:38 2017 The RT System itself - Status changed from 'new' to 'open'

Wed Jun 28 18:41:39 2017 al.dunsmuir [...] sympatico.ca - Correspondence added

From:

al.dunsmuir [...] sympatico.ca

On Tue Jun 27 22:38:37 2017, ETJ wrote: Show quoted text

> Hi Al, > > Thanks for this report. The behaviour you describe as a "corrupt" > value is apparently a deliberate choice as implemented in > init_lib2arch at https://github.com/Perl-Toolchain-Gang/ExtUtils- > MakeMaker/blob/master/lib/ExtUtils/MM_Unix.pm#L1926 - to use the > VENDORLIB for "arch" files if no VENDORARCH supplied. > > I have made a PR which updates the documentation and welcome your > thoughts: https://github.com/Perl-Toolchain-Gang/ExtUtils- > MakeMaker/pull/306/files > > Best regards, > Ed

Ed, The problem is that neither the current nor your documentation update matches the the actual or what I believe is the intended behavior. The Perl configuration process sets up two sets of configuration values: - When building pure Perl (architecture-neutral) components, the files generated by the build are placed in the a common location. Under the convention for building RPMs (Red Hat RHEL, Centos, or Fedora) and most other platforms/distributions this is "noarch". - When building components containing architecture-specific elements (written in C, C++, etc.) the files generated by the build are placed in a directory under the common location. This ensures that each architecture is independent of the other and allows cases such as mine with parallel 32-bit and 64-bit builds. If one is specifying one override for these builds (such as where the generated man.3 pages are to be placed), it is important that specifying one override keyword must not affect the other keyword values. Only that value must change from the configuration values generated during the build of Perl. This is important because if a new output file type is defined, specifying the override for that type must not affect all other file types. Otherwise if one wants to move one file type, you must know ALL affected configuration variables that might change without notice, and specify them all merely to get the standard Perl configuration value. The vendor build system for Perl is designed to create a parallel installable instance of Perl (Perl itself and related modules) that in NO WAY impacts the standard Perl instance. This is important from a security and sanity point of view because modules for one Perl instance may be totally incompatible with the other. Specifying installdirs=vendor uses the alternate (distinct) set of Perl configuration values, so that the output directory names for both noarch and arch-specific files have the same relative relationship as before, but are under an further directory level to ensure that they do not collide with the system default Perl. Note that the use of installdirs=vendor without any further overrides works just fine. Specifying a full set of overrides for either non-vendor or vendor builds works, assuming you know all of the keywords that must be overridden. It is not acceptable is for an individual keyword to be specified, and that value not to be used instead of the original configuration value. Similarly, if a keyword value is not specified, it must end up with the original configuration value - unless that configuration value is related - for example if one changes the location of a tree of directories by changing the root, one EXPECTS that all directories under that root will change. The current behavior is wrong in two ways: - The vendor arch-specific directory is relative to the noarch directory. This relationship is critical - otherwise one could build and _successfully_ test a broken vendor package that when installed will overlay (and likely render non-functional) that package in the system Perl. The whole point of the separate vendor tree is to isolate the system and vendor Perl. Using a directory from the wrong set is unacceptable in either direction, - The whole point of my original problem report is that the value that was generated in the makefile was wrong because IT DOES NOT WORK. Note that one part of the Perl build system placed the files in the wrong directory, but other parts of the build system knew the original directory from the Perl configuration value, and since that value WAS NOT OVERRIDED by the user used that value to look for the files. If you are going to change values for unrelated keywords, you at least need to pick a sane value AND you need to make it so that new value is consistently used and the final result is functional. In this case, I would submit that specifying one keyword in the set of vendor (or non-vendor) keywords should NOT suddenly result in new values for other keywords. If it would result in a new value, that new value must be sane. Note that vendor builds are *not* rare - all RedHat Linux (RHEL, Centos, and Fedora) builds use it for their only Perl instance. The vendor builds must not be treated as some sort of second-class configuration where it is OK to have quirky behavior. Al Dunsmuir

Wed Jun 28 21:44:39 2017 al.dunsmuir [...] sympatico.ca - Correspondence added

From:

al.dunsmuir [...] sympatico.ca

Ed, A few days without much sleep left my answer run on. Let's try again, after a nap 8^). There are 4 quadrants that one can develop a package for: - Standard Perl, noarch - Standard Perl, arch - Vendor Perl, noarch - Vendor Perl, arch Each has a different and incompatible set of directories into which each file within the Perl package must be delivered by the Perl build system. Delivered to the wrong directory, you may end up with a package where the tests pass, but the resulting files are not usable. It may be possible to manipulate the final directories after the fact, but this may result in a final package that does not work because they no longer match paths embedded during build. In the case of 32-bit and 64-bit parallel builds (each to their own separate 32bit and 64bit source/build subtree, you could easily end up with files that collide in the final package if the arch- specific portion of the directories is missing... even though each arch was successfully built and tested. Inadvertently getting noarch when you need arch is just as bad as dropping files into the wrong perl (standard vs vendor) quadrant. In the case that I'm reporting, it worked with my older 5.22.1 setup, (almost 500 packages on AIX) but now fails with 5.26.0 AND a rebuilt 5.22.1 Perl. I had to manually update the build recipes within each package to delete the 2 previously-benign overrides (that actually specified the default configuration values) so that I got the correct INSTALLVENDORARCH value on arch-specific packages (and avoided future issues with noarch). This was after spending time over an elapsed week tracking down the incorrect behavior change. I'd prefer it was fixed in the code so that it does not burn someone else - documenting that each keyword's value can not be trusted if you specify OTHER keywords just does not seem like the right approach. Al

Wed Jun 28 22:52:31 2017 ETJ [...] cpan.org - Correspondence added

Hi Al, I hope you will accept I understand what the "arch" stuff is for, and why it's important. I would need to do more research to discover exactly what has changed for these purposes between 5.22 and 5.26. You said that you get success if you either: * supply both *LIB and *ARCH * supply neither I accept there is a change in behaviour, and that is unfortunate. You're saying you get the behaviour you want if you just supply both variables (I assume "supply neither" is unacceptable since that would use the Config values for arch, which isn't desired). If that works, what are your thoughts on just making the docs reflect that? I'm highly reluctant to change any behaviour in EUMM if we have something that works, since that often creates unintended consequences. Best regards, Ed

Wed Jun 28 23:38:55 2017 al.dunsmuir [...] sympatico.ca - Correspondence added

From:

al.dunsmuir [...] sympatico.ca

On Wed Jun 28 22:52:31 2017, ETJ wrote: Show quoted text

> Hi Al, > > I hope you will accept I understand what the "arch" stuff is for, and > why it's important. > > I would need to do more research to discover exactly what has changed > for these purposes between 5.22 and 5.26. You said that you get > success if you either: > > * supply both *LIB and *ARCH > * supply neither > > I accept there is a change in behaviour, and that is unfortunate. > You're saying you get the behaviour you want if you just supply both > variables (I assume "supply neither" is unacceptable since that would > use the Config values for arch, which isn't desired). If that works, > what are your thoughts on just making the docs reflect that? I'm > highly reluctant to change any behaviour in EUMM if we have something > that works, since that often creates unintended consequences. > > Best regards, > Ed

Ed, Please follow the back trail through the tickets I created in the main Perl5 bug tracker. I've provided ticket# and links back along the trail. If you specify just installdirs=vendor, you get the correct values for both noarch and arch vendor builds. As noted, this is the final solution that I chose to adopt because it helps verify that the main Perl build has the correct configuration values, and minimizes the possibility of problems with variable combinations. It also means the build recipes are the same for arch and noarch .spec files (K.I.S.S. principal). As noted, the Perl 5.26.0 build is updated to incorporate EU::MM to 2.30 to get around the test failures with the default EU::MM shipped in 5.26.0... and also has patches to the ExtUtil::CBuilder that fix issues in building C and C++ files using IBM's XL C/C++ compiler (instead of gcc/g++) - same as my 5.22.1 Perl. Unfortunately, I lost my original 5.22.1 build from last summer when I built and installed a new one with full logs to compare against 5.26.0 - 8^(. The newly built 5.22.1 had the same issue even though the older original one worked just fine with the same RPM .spec and source file. 8^( 8^(. My new .spec files also now build a standardized build.log file and saves it in the source rpm (.src.rpm) file that is built along with the binary .rpm file. It's likely that something has changed in my build environment over the 9 months since my last build... but that interval was effectively much shorter as the AIX system was mostly shut down while I was renovating my basement and (finally) moving my office down there (to avoid sawdust and drywall dust contamination). Whatever it is was subtle, and I have not spotted it. In any case both Perl builds show the correct configuration values and uses them correctly if only the basic "installdir=vendor" is used. Al

Thu Jun 29 00:35:22 2017 ETJ [...] cpan.org - Correspondence added

Al, So it works correctly now if you say "installdirs=vendor" and nothing else? If so, then it seems to me EUMM is now functioning in a comprehensible and consistent way? If that's true, then can we just document a/the "right way" and leave it at that? Best regards, Ed

Thu Jun 29 08:48:55 2017 al.dunsmuir [...] sympatico.ca - Correspondence added

From:

al.dunsmuir [...] sympatico.ca

On Thu Jun 29 00:35:22 2017, ETJ wrote: Show quoted text

> Al, > > So it works correctly now if you say "installdirs=vendor" and nothing > else? If so, then it seems to me EUMM is now functioning in a > comprehensible and consistent way? > > If that's true, then can we just document a/the "right way" and leave > it at that? > > Best regards, > Ed

Ed, The problem is as reported in the start of this bug report and previous tickets that got me here. It would be great to be able to have simply updated the original ticket subject and component so it's all in one place but the bugtracker does not seem to support that for end users. I stated the results with 3 different EU::MM options combinations specified, with one that is clearly broken which needs to be fixed. The tickets show the correct Perl configuration values which are accessed by EU:MM via config.pm and Makefile attachments showing the case where the wrong value is generated. While specifying "installdirs=vendor" by itself works, specifying two of the additional vendor-related keywords WITHOUT specifying that third results in a hidden INCORRECT change for third keyword value in the generated Makefile. This is NOT MATCH in any your proposed update in any way. Because the INSTALLVENDORARCH value in the EU:MM generated Makefile does not match the Config.pm value that EU:MM starts with, and there was no keyword INSTALLVENDORARCH=value specified to EU:MM, it is clearly a bug that this value is changed. As I explained, it is especially bad since this slams all the architecture-specific build output into the no-arch output directory resulting is NON-FUNCTIONAL build that still passes all tests. The only reason I catch it is that the RPM build system looks for the output to appear in the arch-specific directory and fails when it does not. In a pure CPAN environment, you would see the problem if you are running on a multilib system that supports both 32-bit and 64-bit operation, and CPAN tries to build both both 32-bit and 64-bit variations of the same arch-specific package. In looking at the EU:MM code, for AIX this processing is being done in lib/ExtUtils/Unix.pm so I expect this should be EASILY reproducible on Linux. Al

Thu Jun 29 14:17:35 2017 BINGOS [...] cpan.org - Correspondence added

I have been doing some digging through repository history and the behaviour where one defines an installation directory but not an architecture directory is pretty much implemented as described in the comment in sub init_lib2arch() # The user who requests an installation directory explicitly # should not have to tell us an architecture installation directory # as well. We look if a directory exists that is named after the # architecture. If not we take it as a sign that it should be the # same as the requested installation directory. Otherwise we take # the found one. I built and installed a v5.24.1 perl with vendor paths: Built under freebsd Compiled at Jun 16 2017 09:47:23 @INC: /opt/perl-5.24.1/lib/site_perl/5.24.1/amd64-freebsd /opt/perl-5.24.1/lib/site_perl/5.24.1 /opt/perl-5.24.1/lib/vendor_perl/5.24.1/amd64-freebsd /opt/perl-5.24.1/lib/vendor_perl/5.24.1 /opt/perl-5.24.1/lib/5.24.1/amd64-freebsd /opt/perl-5.24.1/lib/5.24.1 . # perl -V:vendorlib vendorlib='/opt/perl-5.24.1/lib/vendor_perl/5.24.1'; # perl -V:vendorarch vendorarch='/opt/perl-5.24.1/lib/vendor_perl/5.24.1/amd64-freebsd'; We have nothing under vendor yet: # ls /opt/perl-5.24.1/lib/vendor_perl/ # I unwrapped the Variable-Magic-0.61 tarball and amended the Makefile.PL to add $ExtUtils::MakeMaker::Verbose=1 5 use ExtUtils::MakeMaker; 6 $ExtUtils::MakeMaker::Verbose=1; 7 use Config; # perl Makefile.PL INSTALLDIRS=vendor INSTALLVENDORLIB=/opt/perl-5.24.1/lib/vendor_perl/5.24.1 Checking if this is ActiveState Perl 5.8.8 build 822 or higher... no Checking if this is gcc 3.4 on Windows trying to link against an import library... no MakeMaker (v7.3) Checking if your kit is complete... Looks good ABSTRACT_FROM => q[lib/Variable/Magic.pm] AUTHOR => [q[Vincent Pit <perl@profvince.com>]] BUILD_REQUIRES => { Carp=>q[0], Config=>q[0], Exporter=>q[0], ExtUtils::MakeMaker=>q[0], IO::Handle=>q[0], IO::Select=>q[0], IPC::Open3=>q[0], POSIX=>q[0], Socket=>q[0], Test::More=>q[0], XSLoader=>q[0], base=>q[0], lib=>q[0] } CONFIGURE_REQUIRES => { } INSTALLDIRS => q[vendor] INSTALLVENDORLIB => q[/opt/perl-5.24.1/lib/vendor_perl/5.24.1] LICENSE => q[perl] META_MERGE => { build_requires=>{ Carp=>q[0], Config=>q[0], Exporter=>q[0], ExtUtils::MakeMaker=>q[0], IO::Handle=>q[0], IO::Select=>q[0], IPC::Open3=>q[0], POSIX=>q[0], Socket=>q[0], Test::More=>q[0], XSLoader=>q[0], base=>q[0], lib=>q[0] }, configure_requires=>{ Config=>q[0], ExtUtils::MakeMaker=>q[0] }, dynamic_config=>q[1], resources=>{ bugtracker=>q[http://rt.cpan.org/Dist/Display.html?Name=Variable-Magic], homepage=>q[http://search.cpan.org/dist/Variable-Magic/], license=>q[http://dev.perl.org/licenses/], repository=>q[http://git.profvince.com/?p=perl%2Fmodules%2FVariable-Magic.git] } } MIN_PERL_VERSION => q[5.008] NAME => q[Variable::Magic] PL_FILES => { } PREREQ_PM => { Carp=>q[0], Exporter=>q[0], XSLoader=>q[0], base=>q[0] } TEST_REQUIRES => { } VERSION_FROM => q[lib/Variable/Magic.pm] clean => { FILES=>q[Variable-Magic-* *.gcov *.gcda *.gcno cover_db Debian_CPANTS.txt*] } dist => { COMPRESS=>q[gzip -9f], PREOP=>q[pod2text -u lib/Variable/Magic.pm > $(DISTVNAME)/README], SUFFIX=>q[gz] } Directory /opt/perl-5.24.1/lib/vendor_perl/5.24.1/amd64-freebsd not found Defaulting INSTALLVENDORARCH to /opt/perl-5.24.1/lib/vendor_perl/5.24.1 Using PERL=/opt/perl-5.24.1/bin/perl Generating a Unix-style Makefile Writing Makefile for Variable::Magic Writing MYMETA.yml and MYMETA.json The important part is "Directory /opt/perl-5.24.1/lib/vendor_perl/5.24.1/amd64-freebsd not found" Let's create that directory: # mkdir -p /opt/perl-5.24.1/lib/vendor_perl/5.24.1/amd64-freebsd And run Makefile.PL again: # perl Makefile.PL INSTALLDIRS=vendor INSTALLVENDORLIB=/opt/perl-5.24.1/lib/vendor_perl/5.24.1 Checking if this is ActiveState Perl 5.8.8 build 822 or higher... no Checking if this is gcc 3.4 on Windows trying to link against an import library... no MakeMaker (v7.3) ABSTRACT_FROM => q[lib/Variable/Magic.pm] AUTHOR => [q[Vincent Pit <perl@profvince.com>]] BUILD_REQUIRES => { Carp=>q[0], Config=>q[0], Exporter=>q[0], ExtUtils::MakeMaker=>q[0], IO::Handle=>q[0], IO::Select=>q[0], IPC::Open3=>q[0], POSIX=>q[0], Socket=>q[0], Test::More=>q[0], XSLoader=>q[0], base=>q[0], lib=>q[0] } CONFIGURE_REQUIRES => { } INSTALLDIRS => q[vendor] INSTALLVENDORLIB => q[/opt/perl-5.24.1/lib/vendor_perl/5.24.1] LICENSE => q[perl] META_MERGE => { build_requires=>{ Carp=>q[0], Config=>q[0], Exporter=>q[0], ExtUtils::MakeMaker=>q[0], IO::Handle=>q[0], IO::Select=>q[0], IPC::Open3=>q[0], POSIX=>q[0], Socket=>q[0], Test::More=>q[0], XSLoader=>q[0], base=>q[0], lib=>q[0] }, configure_requires=>{ Config=>q[0], ExtUtils::MakeMaker=>q[0] }, dynamic_config=>q[1], resources=>{ bugtracker=>q[http://rt.cpan.org/Dist/Display.html?Name=Variable-Magic], homepage=>q[http://search.cpan.org/dist/Variable-Magic/], license=>q[http://dev.perl.org/licenses/], repository=>q[http://git.profvince.com/?p=perl%2Fmodules%2FVariable-Magic.git] } } MIN_PERL_VERSION => q[5.008] NAME => q[Variable::Magic] PL_FILES => { } PREREQ_PM => { Carp=>q[0], Exporter=>q[0], XSLoader=>q[0], base=>q[0] } TEST_REQUIRES => { } VERSION_FROM => q[lib/Variable/Magic.pm] clean => { FILES=>q[Variable-Magic-* *.gcov *.gcda *.gcno cover_db Debian_CPANTS.txt*] } dist => { COMPRESS=>q[gzip -9f], PREOP=>q[pod2text -u lib/Variable/Magic.pm > $(DISTVNAME)/README], SUFFIX=>q[gz] } Defaulting INSTALLVENDORARCH to /opt/perl-5.24.1/lib/vendor_perl/5.24.1/amd64-freebsd Using PERL=/opt/perl-5.24.1/bin/perl Generating a Unix-style Makefile Writing Makefile for Variable::Magic Writing MYMETA.yml and MYMETA.json This time it sets INSTALLVENDORARCH correctly.

Thu Jun 29 15:21:57 2017 al.dunsmuir [...] sympatico.ca - Correspondence added

From:

al.dunsmuir [...] sympatico.ca

On Thu Jun 29 14:17:35 2017, BINGOS wrote: Show quoted text

> I have been doing some digging through repository history and the > behaviour where one defines an installation directory > but not an architecture directory is pretty much implemented as > described in the comment in sub init_lib2arch() > > # The user who requests an installation directory explicitly > # should not have to tell us an architecture installation directory > # as well. We look if a directory exists that is named after the > # architecture. If not we take it as a sign that it should be the > # same as the requested installation directory. Otherwise we take > # the found one. > > I built and installed a v5.24.1 perl with vendor paths: > > Built under freebsd > Compiled at Jun 16 2017 09:47:23 > @INC: > /opt/perl-5.24.1/lib/site_perl/5.24.1/amd64-freebsd > /opt/perl-5.24.1/lib/site_perl/5.24.1 > /opt/perl-5.24.1/lib/vendor_perl/5.24.1/amd64-freebsd > /opt/perl-5.24.1/lib/vendor_perl/5.24.1 > /opt/perl-5.24.1/lib/5.24.1/amd64-freebsd > /opt/perl-5.24.1/lib/5.24.1 > . > > # perl -V:vendorlib > vendorlib='/opt/perl-5.24.1/lib/vendor_perl/5.24.1'; > # perl -V:vendorarch > vendorarch='/opt/perl-5.24.1/lib/vendor_perl/5.24.1/amd64-freebsd'; > > We have nothing under vendor yet: > > # ls /opt/perl-5.24.1/lib/vendor_perl/ > # > > I unwrapped the Variable-Magic-0.61 tarball and amended the > Makefile.PL to add $ExtUtils::MakeMaker::Verbose=1 > > 5 use ExtUtils::MakeMaker; > 6 $ExtUtils::MakeMaker::Verbose=1; > 7 use Config; > > # perl Makefile.PL INSTALLDIRS=vendor INSTALLVENDORLIB=/opt/perl- > 5.24.1/lib/vendor_perl/5.24.1 > Checking if this is ActiveState Perl 5.8.8 build 822 or higher... no > Checking if this is gcc 3.4 on Windows trying to link against an > import library... no > MakeMaker (v7.3) > Checking if your kit is complete... > Looks good > ABSTRACT_FROM => q[lib/Variable/Magic.pm] > AUTHOR => [q[Vincent Pit <perl@profvince.com>]] > BUILD_REQUIRES => { Carp=>q[0], Config=>q[0], Exporter=>q[0], > ExtUtils::MakeMaker=>q[0], IO::Handle=>q[0], IO::Select=>q[0], > IPC::Open3=>q[0], POSIX=>q[0], Socket=>q[0], Test::More=>q[0], > XSLoader=>q[0], base=>q[0], lib=>q[0] } > CONFIGURE_REQUIRES => { } > INSTALLDIRS => q[vendor] > INSTALLVENDORLIB => q[/opt/perl-5.24.1/lib/vendor_perl/5.24.1] > LICENSE => q[perl] > META_MERGE => { build_requires=>{ Carp=>q[0], Config=>q[0], > Exporter=>q[0], ExtUtils::MakeMaker=>q[0], IO::Handle=>q[0], > IO::Select=>q[0], IPC::Open3=>q[0], POSIX=>q[0], Socket=>q[0], > Test::More=>q[0], XSLoader=>q[0], base=>q[0], lib=>q[0] }, > configure_requires=>{ Config=>q[0], ExtUtils::MakeMaker=>q[0] }, > dynamic_config=>q[1], resources=>{ > bugtracker=>q[http://rt.cpan.org/Dist/Display.html?Name=Variable- > Magic], homepage=>q[http://search.cpan.org/dist/Variable-Magic/], > license=>q[http://dev.perl.org/licenses/], > repository=>q[http://git.profvince.com/?p=perl%2Fmodules%2FVariable- > Magic.git] } } > MIN_PERL_VERSION => q[5.008] > NAME => q[Variable::Magic] > PL_FILES => { } > PREREQ_PM => { Carp=>q[0], Exporter=>q[0], XSLoader=>q[0], > base=>q[0] } > TEST_REQUIRES => { } > VERSION_FROM => q[lib/Variable/Magic.pm] > clean => { FILES=>q[Variable-Magic-* *.gcov *.gcda *.gcno cover_db > Debian_CPANTS.txt*] } > dist => { COMPRESS=>q[gzip -9f], PREOP=>q[pod2text -u > lib/Variable/Magic.pm > $(DISTVNAME)/README], SUFFIX=>q[gz] } > Directory /opt/perl-5.24.1/lib/vendor_perl/5.24.1/amd64-freebsd not > found > Defaulting INSTALLVENDORARCH to /opt/perl- > 5.24.1/lib/vendor_perl/5.24.1 > Using PERL=/opt/perl-5.24.1/bin/perl > Generating a Unix-style Makefile > Writing Makefile for Variable::Magic > Writing MYMETA.yml and MYMETA.json > > The important part is "Directory /opt/perl- > 5.24.1/lib/vendor_perl/5.24.1/amd64-freebsd not found" > > Let's create that directory: > > # mkdir -p /opt/perl-5.24.1/lib/vendor_perl/5.24.1/amd64-freebsd > > And run Makefile.PL again: > > # perl Makefile.PL INSTALLDIRS=vendor INSTALLVENDORLIB=/opt/perl- > 5.24.1/lib/vendor_perl/5.24.1 > Checking if this is ActiveState Perl 5.8.8 build 822 or higher... no > Checking if this is gcc 3.4 on Windows trying to link against an > import library... no > MakeMaker (v7.3) > ABSTRACT_FROM => q[lib/Variable/Magic.pm] > AUTHOR => [q[Vincent Pit <perl@profvince.com>]] > BUILD_REQUIRES => { Carp=>q[0], Config=>q[0], Exporter=>q[0], > ExtUtils::MakeMaker=>q[0], IO::Handle=>q[0], IO::Select=>q[0], > IPC::Open3=>q[0], POSIX=>q[0], Socket=>q[0], Test::More=>q[0], > XSLoader=>q[0], base=>q[0], lib=>q[0] } > CONFIGURE_REQUIRES => { } > INSTALLDIRS => q[vendor] > INSTALLVENDORLIB => q[/opt/perl-5.24.1/lib/vendor_perl/5.24.1] > LICENSE => q[perl] > META_MERGE => { build_requires=>{ Carp=>q[0], Config=>q[0], > Exporter=>q[0], ExtUtils::MakeMaker=>q[0], IO::Handle=>q[0], > IO::Select=>q[0], IPC::Open3=>q[0], POSIX=>q[0], Socket=>q[0], > Test::More=>q[0], XSLoader=>q[0], base=>q[0], lib=>q[0] }, > configure_requires=>{ Config=>q[0], ExtUtils::MakeMaker=>q[0] }, > dynamic_config=>q[1], resources=>{ > bugtracker=>q[http://rt.cpan.org/Dist/Display.html?Name=Variable- > Magic], homepage=>q[http://search.cpan.org/dist/Variable-Magic/], > license=>q[http://dev.perl.org/licenses/], > repository=>q[http://git.profvince.com/?p=perl%2Fmodules%2FVariable- > Magic.git] } } > MIN_PERL_VERSION => q[5.008] > NAME => q[Variable::Magic] > PL_FILES => { } > PREREQ_PM => { Carp=>q[0], Exporter=>q[0], XSLoader=>q[0], > base=>q[0] } > TEST_REQUIRES => { } > VERSION_FROM => q[lib/Variable/Magic.pm] > clean => { FILES=>q[Variable-Magic-* *.gcov *.gcda *.gcno cover_db > Debian_CPANTS.txt*] } > dist => { COMPRESS=>q[gzip -9f], PREOP=>q[pod2text -u > lib/Variable/Magic.pm > $(DISTVNAME)/README], SUFFIX=>q[gz] } > Defaulting INSTALLVENDORARCH to /opt/perl- > 5.24.1/lib/vendor_perl/5.24.1/amd64-freebsd > Using PERL=/opt/perl-5.24.1/bin/perl > Generating a Unix-style Makefile > Writing Makefile for Variable::Magic > Writing MYMETA.yml and MYMETA.json

Chris, Thank you for your assistance! In ticket 131415 Perl 5.24+ Configure loses hints script changes https://rt.perl.org/Ticket/Display.html?id=131415 I have some details, but without the EU::MM Verbose flag set. Look for "A test 5.26.0 build of perl-Variable-Magic completed the perl-specific build and test successfully, but failed during the rpm install/packaging related portion." Since the hints portion of the issue was fixed by removing a bogus Configure line, I started a new ticket to track this #131559: ExtUtils::Command::MM not installing files in vendor arch-specific directories https://rt.perl.org/Ticket/Display.html?id=131559 It has attachments for Makefile generated by MakeMaker which shows the arch-specific install directory missing the arch (ppc-thread-multilib) suffix, even though it was present in the Perl configuration accessed by Config.pm in EU::MM. Without the RPM packaging failure after the Perl package build complets, the arch-specific files were silently placed in the noarch directory. I will do whatever builds you need with the EU:MM verbose output enabled to help track this down. Because the build is under rpm, I'll need to update the Makefile.PL via a patch. I was thinking of doing the build for all 3 variations (just installvendor, installvendor plus 2 overrides, install vendor plus the 3 overrides). I would attach the full build.log files and the generated Makefiles. Hopefully this would give you enough information to determine why the 2nd case ends up with a bad value for INSTALLVARCHVENDOR. Worse case, I can repeat after patching in some code to emit more verbose debug output from EU:MM. I'd be doing this sometime this weekend. Is there anything else that you wish to see? Al

Tue Jan 28 18:10:43 2020 jkeenan [...] cpan.org - Correspondence added

On Thu Jun 29 15:21:57 2017, al.dunsmuir@sympatico.ca wrote: Show quoted text

> On Thu Jun 29 14:17:35 2017, BINGOS wrote:

> > I have been doing some digging through repository history and the > > behaviour where one defines an installation directory > > but not an architecture directory is pretty much implemented as > > described in the comment in sub init_lib2arch() > > > > # The user who requests an installation directory explicitly > > # should not have to tell us an architecture installation directory > > # as well. We look if a directory exists that is named after the > > # architecture. If not we take it as a sign that it should be the > > # same as the requested installation directory. Otherwise we take > > # the found one. > > > > I built and installed a v5.24.1 perl with vendor paths: > > > > Built under freebsd > > Compiled at Jun 16 2017 09:47:23 > > @INC: > > /opt/perl-5.24.1/lib/site_perl/5.24.1/amd64-freebsd > > /opt/perl-5.24.1/lib/site_perl/5.24.1 > > /opt/perl-5.24.1/lib/vendor_perl/5.24.1/amd64-freebsd > > /opt/perl-5.24.1/lib/vendor_perl/5.24.1 > > /opt/perl-5.24.1/lib/5.24.1/amd64-freebsd > > /opt/perl-5.24.1/lib/5.24.1 > > . > > > > # perl -V:vendorlib > > vendorlib='/opt/perl-5.24.1/lib/vendor_perl/5.24.1'; > > # perl -V:vendorarch > > vendorarch='/opt/perl-5.24.1/lib/vendor_perl/5.24.1/amd64-freebsd'; > > > > We have nothing under vendor yet: > > > > # ls /opt/perl-5.24.1/lib/vendor_perl/ > > # > > > > I unwrapped the Variable-Magic-0.61 tarball and amended the > > Makefile.PL to add $ExtUtils::MakeMaker::Verbose=1 > > > > 5 use ExtUtils::MakeMaker; > > 6 $ExtUtils::MakeMaker::Verbose=1; > > 7 use Config; > > > > # perl Makefile.PL INSTALLDIRS=vendor INSTALLVENDORLIB=/opt/perl- > > 5.24.1/lib/vendor_perl/5.24.1 > > Checking if this is ActiveState Perl 5.8.8 build 822 or higher... no > > Checking if this is gcc 3.4 on Windows trying to link against an > > import library... no > > MakeMaker (v7.3) > > Checking if your kit is complete... > > Looks good > > ABSTRACT_FROM => q[lib/Variable/Magic.pm] > > AUTHOR => [q[Vincent Pit <perl@profvince.com>]] > > BUILD_REQUIRES => { Carp=>q[0], Config=>q[0], Exporter=>q[0], > > ExtUtils::MakeMaker=>q[0], IO::Handle=>q[0], IO::Select=>q[0], > > IPC::Open3=>q[0], POSIX=>q[0], Socket=>q[0], Test::More=>q[0], > > XSLoader=>q[0], base=>q[0], lib=>q[0] } > > CONFIGURE_REQUIRES => { } > > INSTALLDIRS => q[vendor] > > INSTALLVENDORLIB => q[/opt/perl-5.24.1/lib/vendor_perl/5.24.1] > > LICENSE => q[perl] > > META_MERGE => { build_requires=>{ Carp=>q[0], Config=>q[0], > > Exporter=>q[0], ExtUtils::MakeMaker=>q[0], IO::Handle=>q[0], > > IO::Select=>q[0], IPC::Open3=>q[0], POSIX=>q[0], Socket=>q[0], > > Test::More=>q[0], XSLoader=>q[0], base=>q[0], lib=>q[0] }, > > configure_requires=>{ Config=>q[0], ExtUtils::MakeMaker=>q[0] }, > > dynamic_config=>q[1], resources=>{ > > bugtracker=>q[http://rt.cpan.org/Dist/Display.html?Name=Variable- > > Magic], homepage=>q[http://search.cpan.org/dist/Variable-Magic/], > > license=>q[http://dev.perl.org/licenses/], > > repository=>q[http://git.profvince.com/?p=perl%2Fmodules%2FVariable- > > Magic.git] } } > > MIN_PERL_VERSION => q[5.008] > > NAME => q[Variable::Magic] > > PL_FILES => { } > > PREREQ_PM => { Carp=>q[0], Exporter=>q[0], XSLoader=>q[0], > > base=>q[0] } > > TEST_REQUIRES => { } > > VERSION_FROM => q[lib/Variable/Magic.pm] > > clean => { FILES=>q[Variable-Magic-* *.gcov *.gcda *.gcno cover_db > > Debian_CPANTS.txt*] } > > dist => { COMPRESS=>q[gzip -9f], PREOP=>q[pod2text -u > > lib/Variable/Magic.pm > $(DISTVNAME)/README], SUFFIX=>q[gz] } > > Directory /opt/perl-5.24.1/lib/vendor_perl/5.24.1/amd64-freebsd not > > found > > Defaulting INSTALLVENDORARCH to /opt/perl- > > 5.24.1/lib/vendor_perl/5.24.1 > > Using PERL=/opt/perl-5.24.1/bin/perl > > Generating a Unix-style Makefile > > Writing Makefile for Variable::Magic > > Writing MYMETA.yml and MYMETA.json > > > > The important part is "Directory /opt/perl- > > 5.24.1/lib/vendor_perl/5.24.1/amd64-freebsd not found" > > > > Let's create that directory: > > > > # mkdir -p /opt/perl-5.24.1/lib/vendor_perl/5.24.1/amd64-freebsd > > > > And run Makefile.PL again: > > > > # perl Makefile.PL INSTALLDIRS=vendor INSTALLVENDORLIB=/opt/perl- > > 5.24.1/lib/vendor_perl/5.24.1 > > Checking if this is ActiveState Perl 5.8.8 build 822 or higher... no > > Checking if this is gcc 3.4 on Windows trying to link against an > > import library... no > > MakeMaker (v7.3) > > ABSTRACT_FROM => q[lib/Variable/Magic.pm] > > AUTHOR => [q[Vincent Pit <perl@profvince.com>]] > > BUILD_REQUIRES => { Carp=>q[0], Config=>q[0], Exporter=>q[0], > > ExtUtils::MakeMaker=>q[0], IO::Handle=>q[0], IO::Select=>q[0], > > IPC::Open3=>q[0], POSIX=>q[0], Socket=>q[0], Test::More=>q[0], > > XSLoader=>q[0], base=>q[0], lib=>q[0] } > > CONFIGURE_REQUIRES => { } > > INSTALLDIRS => q[vendor] > > INSTALLVENDORLIB => q[/opt/perl-5.24.1/lib/vendor_perl/5.24.1] > > LICENSE => q[perl] > > META_MERGE => { build_requires=>{ Carp=>q[0], Config=>q[0], > > Exporter=>q[0], ExtUtils::MakeMaker=>q[0], IO::Handle=>q[0], > > IO::Select=>q[0], IPC::Open3=>q[0], POSIX=>q[0], Socket=>q[0], > > Test::More=>q[0], XSLoader=>q[0], base=>q[0], lib=>q[0] }, > > configure_requires=>{ Config=>q[0], ExtUtils::MakeMaker=>q[0] }, > > dynamic_config=>q[1], resources=>{ > > bugtracker=>q[http://rt.cpan.org/Dist/Display.html?Name=Variable- > > Magic], homepage=>q[http://search.cpan.org/dist/Variable-Magic/], > > license=>q[http://dev.perl.org/licenses/], > > repository=>q[http://git.profvince.com/?p=perl%2Fmodules%2FVariable- > > Magic.git] } } > > MIN_PERL_VERSION => q[5.008] > > NAME => q[Variable::Magic] > > PL_FILES => { } > > PREREQ_PM => { Carp=>q[0], Exporter=>q[0], XSLoader=>q[0], > > base=>q[0] } > > TEST_REQUIRES => { } > > VERSION_FROM => q[lib/Variable/Magic.pm] > > clean => { FILES=>q[Variable-Magic-* *.gcov *.gcda *.gcno cover_db > > Debian_CPANTS.txt*] } > > dist => { COMPRESS=>q[gzip -9f], PREOP=>q[pod2text -u > > lib/Variable/Magic.pm > $(DISTVNAME)/README], SUFFIX=>q[gz] } > > Defaulting INSTALLVENDORARCH to /opt/perl- > > 5.24.1/lib/vendor_perl/5.24.1/amd64-freebsd > > Using PERL=/opt/perl-5.24.1/bin/perl > > Generating a Unix-style Makefile > > Writing Makefile for Variable::Magic > > Writing MYMETA.yml and MYMETA.json

> > Chris, > > Thank you for your assistance! > > In ticket 131415 Perl 5.24+ Configure loses hints script changes > https://rt.perl.org/Ticket/Display.html?id=131415 > > I have some details, but without the EU::MM Verbose flag set. > Look for "A test 5.26.0 build of perl-Variable-Magic completed the > perl-specific build and test successfully, but failed > during the rpm install/packaging related portion." > > Since the hints portion of the issue was fixed by removing a > bogus Configure line, I started a new ticket to track this > #131559: ExtUtils::Command::MM not installing files in vendor arch- > specific directories > https://rt.perl.org/Ticket/Display.html?id=131559 > > It has attachments for Makefile generated by MakeMaker which shows > the arch-specific install directory missing the arch (ppc-thread- > multilib) > suffix, even though it was present in the Perl configuration accessed > by > Config.pm in EU::MM. Without the RPM packaging failure after the Perl > package build complets, the arch-specific files were silently placed > in > the noarch directory. > > I will do whatever builds you need with the EU:MM verbose output > enabled > to help track this down. Because the build is under rpm, I'll need > to > update the Makefile.PL via a patch. I was thinking of doing the > build > for all 3 variations (just installvendor, installvendor plus 2 > overrides, > install vendor plus the 3 overrides). I would attach the full > build.log > files and the generated Makefiles. Hopefully this would give you > enough > information to determine why the 2nd case ends up with a bad value > for > INSTALLVARCHVENDOR. Worse case, I can repeat after patching in some > code > to emit more verbose debug output from EU:MM. > > I'd be doing this sometime this weekend. Is there anything else that > you > wish to see? > > Al

Would it be possible to get an update on the status of this ticket? The Perl 5 bug ticket on which it has a bearing has been migrated to a github issue: https://github.com/Perl/perl5/issues/15992 Thank you very much. Jim Keenan