Bug #91412 for Module-Build-Tiny: Problem Building RPMs From Module::Build::Tiny Modules

Sat Dec 14 03:41:29 2013 DAVECROSS [...] cpan.org - Ticket created

Subject:

Problem Building RPMs From Module::Build::Tiny Modules

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.

Sat Dec 14 07:53:09 2013 LEONT [...] cpan.org - Correspondence added

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

Sat Dec 14 07:53:11 2013 The RT System itself - Status changed from 'new' to 'open'

Sat Dec 14 08:40:01 2013 DAVECROSS [...] cpan.org - Correspondence added

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...

Sat Dec 14 11:55:57 2013 LEONT [...] cpan.org - Correspondence added

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

Sun Jul 27 14:01:07 2014 ether [...] cpan.org - Correspondence added

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.

Tue Aug 12 07:56:20 2014 LEONT [...] cpan.org - Status changed from 'open' to 'rejected'