Skip Menu |

This queue is for tickets about the Asm-X86 CPAN distribution.

Report information
The Basics
Id: 128124
Status: resolved
Worked: 2 hours (120 min)
Priority: 0/
Queue: Asm-X86

People
Owner: BOGDRO [...] cpan.org
Requestors: ANDK [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Wishlist
Broken in: 0.26
Fixed in: 0.27



Subject: Motivation of INSTALLDIRS=vendor explainable?
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,
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).
On Fri Dec 28 17:51:06 2018, BOGDRO wrote: Show quoted text
> On Fri Dec 28 06:15:52 2018, ANDK wrote:
> > 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.
[...] Hi again. Changing from 'vendor' to 'site' apparently changes the location of the manual pages and this fails the RPM build: File not found using glob: /home/bogdan/rpmbuild/BUILDROOT/perl-Asm-X86-0.27-1-omv2015.0.noarch-buildroot/usr/share/man/man3/* Found installed (but unpackaged) files: /usr/local/share/man/man3/Asm::X86.3pm When I got over this somehow, RPM validation fails on my system: perl-Asm-X86.noarch: W: siteperl-in-perl-module /usr/lib/perl5/site_perl/5.20.3/Asm perl-Asm-X86.noarch: W: siteperl-in-perl-module /usr/lib/perl5/site_perl/5.20.3/Asm/X86.pm perl-Asm-X86.noarch: E: dir-or-file-in-usr-local (Badness: 50) /usr/local/share/man/man3/Asm::X86.3pm (none): E: badness 50 exceeds threshold 49. So, at least for now, I need it to stay as-is, to be able to build packages (apparently installing into "site" is a bad thing from an RPM's point of view). Maybe I'll pick this issue after some time, when rpmbuild/rpmlint rules are updated, or I figure out some other way to use "site" and yet be still correct. Maybe it's just an issue of my system's configuration. Hope I've explained enough.
Thanks a lot for your thoughts. Maybe you could also settle somehow with something along the lines %{__perl} Makefile.PL INSTALLDIRS=vendor somewhere in your rpmbuild infrastructure. In other words, give the RPM universe the `vendor` and leave the Makefile.PL agnostic of the INSTALLDIRS option. That would probably provide the best solution. Unfortunately I don't know where exactly this line would live. Either way, the amount of harm happening will be tiny. Feel free to resolve the issue to get rid of the open ticket. Thanks again!
On Sun Dec 30 01:34:03 2018, ANDK wrote: Show quoted text
> Thanks a lot for your thoughts. > > Maybe you could also settle somehow with something along the lines > > %{__perl} Makefile.PL INSTALLDIRS=vendor > > somewhere in your rpmbuild infrastructure. > > In other words, give the RPM universe the `vendor` and leave the > Makefile.PL agnostic of the INSTALLDIRS option. That would probably > provide the best solution. Unfortunately I don't know where exactly > this line would live. > > Either way, the amount of harm happening will be tiny. Feel free to > resolve the issue to get rid of the open ticket. > > Thanks again!
I have successfully managed to do that. I've uploaded 0.27 with INSTALLDIRS totally removed from Makefile.PL (like it was before). Please confirm that it works for you.
CC: ANDK [...] cpan.org
Subject: Re: [rt.cpan.org #128124] Motivation of INSTALLDIRS=vendor explainable?
Date: Thu, 03 Jan 2019 20:16:22 +0100
To: "Bogdan Drozdowski via RT" <bug-Asm-X86 [...] rt.cpan.org>
From: Andreas Koenig <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>
Show quoted text
>>>>> On Thu, 3 Jan 2019 13:32:21 -0500, "Bogdan Drozdowski via RT" <bug-Asm-X86@rt.cpan.org> said:
Show quoted text
> I have successfully managed to do that. I've uploaded 0.27 with > INSTALLDIRS totally removed from Makefile.PL (like it was before). > Please confirm that it works for you.
Confirming: my smokers just produced 20 pass reports and no fail report. Thank you very much! -- andreas
On Thu Jan 03 14:16:39 2019, andreas.koenig.7os6VVqR@franz.ak.mind.de wrote: Show quoted text
> >>>>> On Thu, 3 Jan 2019 13:32:21 -0500, "Bogdan Drozdowski via RT" > >>>>> <bug-Asm-X86@rt.cpan.org> said:
>
> > I have successfully managed to do that. I've uploaded 0.27 with > > INSTALLDIRS totally removed from Makefile.PL (like it was before). > > Please confirm that it works for you.
> > Confirming: my smokers just produced 20 pass reports and no fail > report. > > Thank you very much!
Thanks for the confirmation, marking the ticket as fixed & resolved.