Skip Menu |
 

This queue is for tickets about the Module-Build-Tiny CPAN distribution.

Report information
The Basics
Id: 91412
Status: rejected
Priority: 0/
Queue: Module-Build-Tiny

People
Owner: Nobody in particular
Requestors: DAVECROSS [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Problem Building RPMs From Module::Build::Tiny Modules
Download (untitled) / with headers
text/plain 1.3k
Hi, I'm trying to build an RPM of LWP::Protocol::PSGI. I'm using cpanspec and rpmbuild in a way that works fine for modules based on EU::MM and Module::Build. $ cpanspec LWP::Protocol::PSGI This downloads the tarball from CPAN, parses it and builds a .spec file. The spec file contains (among many others) these lines: %build %{__perl} Build.PL installdirs=vendor ./Build %install rm -rf $RPM_BUILD_ROOT ./Build install destdir=$RPM_BUILD_ROOT create_packlist=0 (Where $RPM_BUILD_ROOT points to a temp directory under my home directory where I build RPMs) I then use "rpmbuild -ba perl-LWP-Protocol-PSGI.spec" to build the RPM. Part of the output I get is this: + rm -rf /home/dave/rpm/BUILDROOT/perl-LWP-Protocol-PSGI-0.06-1.fc19.x86_64 + ./Build install destdir=/home/dave/rpm/BUILDROOT/perl-LWP-Protocol-PSGI-0.06-1.fc19.x86_64 create_packlist=0 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ERROR: Can't create '/usr/local/share/man/man3' Do not have write permissions on '/usr/local/share/man/man3' !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! at /usr/share/perl5/vendor_perl/Module/Build/Tiny.pm line 104. error: Bad exit status from /var/tmp/rpm-tmp.Dwt5Jx (%install) So it seems that M::B::T is ignoring the 'destdir' parameter when deciding where to install the man pages. This is different behavior to that of both EU::MM and Module::Build.
Download (untitled) / with headers
text/plain 1.8k
On Sat Dec 14 03:41:29 2013, DAVECROSS wrote: Show quoted text
> Hi, > > I'm trying to build an RPM of LWP::Protocol::PSGI. I'm using cpanspec > and rpmbuild in a way that works fine for modules based on EU::MM and > Module::Build. > > $ cpanspec LWP::Protocol::PSGI > > This downloads the tarball from CPAN, parses it and builds a .spec > file. The spec file contains (among many others) these lines: > > %build > %{__perl} Build.PL installdirs=vendor > ./Build > > %install > rm -rf $RPM_BUILD_ROOT > > ./Build install destdir=$RPM_BUILD_ROOT create_packlist=0 > > (Where $RPM_BUILD_ROOT points to a temp directory under my home > directory where I build RPMs) > > I then use "rpmbuild -ba perl-LWP-Protocol-PSGI.spec" to build the > RPM. Part of the output I get is this: > > + rm -rf /home/dave/rpm/BUILDROOT/perl-LWP-Protocol-PSGI-0.06- > 1.fc19.x86_64 > + ./Build install destdir=/home/dave/rpm/BUILDROOT/perl-LWP-Protocol- > PSGI-0.06-1.fc19.x86_64 create_packlist=0 > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > ERROR: Can't create '/usr/local/share/man/man3' > Do not have write permissions on '/usr/local/share/man/man3' > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > at /usr/share/perl5/vendor_perl/Module/Build/Tiny.pm line 104. > error: Bad exit status from /var/tmp/rpm-tmp.Dwt5Jx (%install) > > So it seems that M::B::T is ignoring the 'destdir' parameter when > deciding where to install the man pages. This is different behavior to > that of both EU::MM and Module::Build.
This issue is also #85006, #86240 and #88067, and has been documented since 0.027 in the Incompatibilities section. I sent a pull request (https://github.com/silug/cpanspec/pull/5) to have this fixed in cpanspec 7 months ago, but so far got no response (I've just sent him an email hoping that works better). Leon
Download (untitled) / with headers
text/plain 2.3k
On Sat Dec 14 07:53:09 2013, LEONT wrote: Show quoted text
> On Sat Dec 14 03:41:29 2013, DAVECROSS wrote:
> > Hi, > > > > I'm trying to build an RPM of LWP::Protocol::PSGI. I'm using cpanspec > > and rpmbuild in a way that works fine for modules based on EU::MM and > > Module::Build. > > > > $ cpanspec LWP::Protocol::PSGI > > > > This downloads the tarball from CPAN, parses it and builds a .spec > > file. The spec file contains (among many others) these lines: > > > > %build > > %{__perl} Build.PL installdirs=vendor > > ./Build > > > > %install > > rm -rf $RPM_BUILD_ROOT > > > > ./Build install destdir=$RPM_BUILD_ROOT create_packlist=0 > > > > (Where $RPM_BUILD_ROOT points to a temp directory under my home > > directory where I build RPMs) > > > > I then use "rpmbuild -ba perl-LWP-Protocol-PSGI.spec" to build the > > RPM. Part of the output I get is this: > > > > + rm -rf /home/dave/rpm/BUILDROOT/perl-LWP-Protocol-PSGI-0.06- > > 1.fc19.x86_64 > > + ./Build install destdir=/home/dave/rpm/BUILDROOT/perl-LWP-Protocol- > > PSGI-0.06-1.fc19.x86_64 create_packlist=0 > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > ERROR: Can't create '/usr/local/share/man/man3' > > Do not have write permissions on '/usr/local/share/man/man3' > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > at /usr/share/perl5/vendor_perl/Module/Build/Tiny.pm line 104. > > error: Bad exit status from /var/tmp/rpm-tmp.Dwt5Jx (%install) > > > > So it seems that M::B::T is ignoring the 'destdir' parameter when > > deciding where to install the man pages. This is different behavior > > to > > that of both EU::MM and Module::Build.
> > This issue is also #85006, #86240 and #88067, and has been documented > since 0.027 in the Incompatibilities section. I sent a pull request > (https://github.com/silug/cpanspec/pull/5) to have this fixed in > cpanspec 7 months ago, but so far got no response (I've just sent him > an email hoping that works better). > > Leon
Hmm... not convinced that this is a bug in cpanspec, given that it works fine with EU::MM and Module::Build. Seems a bit strange to produce a new too that doesn't work with an important part of many people's toolchain. However, seems that I have a workaround which will allow me to carry on building RPMs while you and the cpanspec author work out your differences :-) Cheers, Dave...
Download (untitled) / with headers
text/plain 1.6k
On Sat Dec 14 08:40:01 2013, DAVECROSS wrote: Show quoted text
> Hmm... not convinced that this is a bug in cpanspec, given that it > works fine with EU::MM and Module::Build. Seems a bit strange to > produce a new too that doesn't work with an important part of many > people's toolchain.
It has absolutely nothing to do with EU::MM, that has it's own ideas of argument handling. Module::Build::Tiny implements a subset of the functionality of Module::Build, which happens to be a strict superset of the functionality that is currently specced. Module::Build accepts just about any argument convention under the rainbow (verbose=1, --verbose, --verbose 1, --verbose=1, --no-verbose, --noverbose, --no_verbose) in an unpleasantly heuristic and opportunistic manner. Getopt::Long can only parse 5 of those (but only 3 at a time). Module::Build is full of stuff like this that's unreasonably complicated to re-implement and specify for no particular reason. There isn't anything else that can handle it either. It's not only far less work for the external toolchain to change (the work for both deb and rpm was trivial, haven't heard from others but in the best case this went unnoticed), the end-result is also far more sane and is backwards compatible with the past 10 years of Module::Build. So yes, we knew this could give some breakage, I consider that unavoidable. Show quoted text
> However, seems that I have a workaround which will allow me to carry > on building RPMs while you and the cpanspec author work out your > differences :-)
It's not just me; I'm following the spec. if he or anyone else disagrees he should file a bug with the spec and then the toolchain gang as a whole will need to work it out with them. Leon
On 2013-12-14 08:55:57, LEONT wrote: Show quoted text
> On Sat Dec 14 08:40:01 2013, DAVECROSS wrote:
> > Hmm... not convinced that this is a bug in cpanspec, given that it > > works fine with EU::MM and Module::Build. Seems a bit strange to > > produce a new too that doesn't work with an important part of many > > people's toolchain.
> > It has absolutely nothing to do with EU::MM, that has it's own ideas > of argument handling. Module::Build::Tiny implements a subset of the > functionality of Module::Build, which happens to be a strict superset > of the functionality that is currently specced. > > Module::Build accepts just about any argument convention under the > rainbow (verbose=1, --verbose, --verbose 1, --verbose=1, --no-verbose, > --noverbose, --no_verbose) in an unpleasantly heuristic and > opportunistic manner. Getopt::Long can only parse 5 of those (but only > 3 at a time). Module::Build is full of stuff like this that's > unreasonably complicated to re-implement and specify for no particular > reason. There isn't anything else that can handle it either. > > It's not only far less work for the external toolchain to change (the > work for both deb and rpm was trivial, haven't heard from others but > in the best case this went unnoticed), the end-result is also far more > sane and is backwards compatible with the past 10 years of > Module::Build. > > So yes, we knew this could give some breakage, I consider that > unavoidable. >
> > However, seems that I have a workaround which will allow me to carry > > on building RPMs while you and the cpanspec author work out your > > differences :-)
> > It's not just me; I'm following the spec. if he or anyone else > disagrees he should file a bug with the spec and then the toolchain > gang as a whole will need to work it out with them. > > Leon
It sounds like it might be reasonable to start phasing out these uses of unspecified options in Module::Build, too (start warning loudly when they are used, then eventually remove them). Let the howls about backcompat breakage begin.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.