On Fri Dec 28 06:15:52 2018, ANDK wrote:
Show quoted text> It took me a while to discover this line in the Makefile.PL:
>
>
https://metacpan.org/source/BOGDRO/Asm-X86-0.26/Makefile.PL#L17
>
> INSTALLDIRS => 'vendor',
>
> If I understand correctly, the effect of this line for an enduser
> usually would be that the package installs into the parts of the
> installation trees that are meant to be used by the vendor which a
> normal user isn't. I wonder whether this is the intended behaviour.
>
> For users who own their perl installation themselves this means that
> the default installation directory gets overruled and the installation
> fails because they do not have permissions to write to the vendor
> directory.
>
> For users who use root permissions to install the package it means
> that they might overwrite files provided by the vendor.
>
> The manpage of ExtUtils::MakeMaker is a bit coy on the matter to
> provide guidance whether it is a good idea when a CPAN author sets the
> INSTALLDIRS default for their users. This is why I ask for the
> motivation.
>
> My personal workaround will probably be this distroprefs file:
>
https://github.com/andk/cpanpm/blob/master/distroprefs/BOGDRO.Asm-
> X86.yml
>
> Thanks for your considerations && Regards,
Hello.
Thanks for the report, it gives a useful point of view. Let me explain myself. Let's start with that I'm not a Perl expert hosting my own installation trees etc.
I'm using the toolchain App-CPANtoRPM -> rpmbuild -> implicit rpmlint. I used a different chain previously and this is my first attempt of this one.
When INSTALLDIRS was not provided, one of the tools complained.
I believe that INSTALLDIRS=site caused one of the tools to complain as well. I'll re-check it for you though.
The motivation was to:
1) make the validation tools stop complaining (fix issues now considered to be package errors),
2) be able to build an RPM file.
I didn't take anyone's manual installation into account. I realize that it is possible, but system-wide installations should be done with system-type packages (RPM, DEB, whatever), that's why the ability to build an RPM is more important to me. From this point of view, this is a vendor's installation.
Whether or not ExtUtils::MakeMaker is user-friendly/documented enough and whether or not rpmbuild + rpmlint do the right thing for everyone, not just for the authors, is another story. But I guess they've been widely used for a long time now, so their authors certianly had the idea what a package should look like, explained the idea and I guess I should follow their advise/experience (even though maybe I'm not doing it completely correctly).