Skip Menu |

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

Report information
The Basics
Id: 54740
Status: open
Priority: 0/
Queue: Module-Build
People
Owner: Nobody in particular
Requestors: craig [...] animalhead.com
Cc:
AdminCc:
Bug Information
Severity: Unimportant
Broken in: (no value)
Fixed in: (no value)

History Show all quoted text
  Thu Feb 18 03:44:30 2010 craig [...] animalhead.com - Ticket created
Subject: Manifying not done during ./Build test
Date: Thu, 18 Feb 2010 00:43:24 -0800
To: bug-Module-Build [...] rt.cpan.org
From: craig [...] animalhead.com
The following log shows a sneaky problem with Module::Build. If I do the following 3 steps: perl Build.PL ./Build test sudo ./Build install the following 2 steps don't happen until the install operation: Manifying blib/lib/IP/World.pod -> blib/libdoc/IP::World.3 Manifying blib/lib/IP/World/ConfigData.pm -> blib/libdoc/ IP::World::ConfigData.3 Because these happen under a sudo, they end up owned by root:wheel with permissions 644. This makes a step like ./Build realclean fail because of insufficient privelege. OTOH, if I enter a './Build' between 'perl Build.PL' and 'Build test', the Manifying steps get done at the end of the './Build' and so the above problem does not occur. If you need any further info, please reply and tell me what. Best Regards, cmac ----------------------------------------------------------------------- animalhead:/build/IP-World $ sudo ./Build distclean Cleaning up build files Cleaning up configuration files animalhead:/build/IP-World $ perl Build.PL --verbose Checking whether your kit is complete... Looks good Adding to configure_requires: Module::Build => 0.36 Checking if compiler tools configured... ok. Checking prerequisites... Looks good Should the DB-update utility run a command when the DB is updated? If so enter it (if not just return): Creating new 'MYMETA.yml' with configuration results Creating new 'Build' script for 'IP-World' version '0.15' animalhead:/build/IP-World $ ./Build test Copying lib/IP/World.pm -> blib/lib/IP/World.pm lib/IP/World.xs -> lib/IP/World.c cc -I/usr/local/lib/perl5/5.10.1/i386-freebsd/CORE -DXS_VERSION="0.15" -DVERSION="0.15" -DPIC -fPIC -DMMAPOK -c -DHAS_FPSETMASK - DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -I/usr/local/include - O3 -o lib/IP/World.o lib/IP/World.c ExtUtils::Mkbootstrap::Mkbootstrap('blib/arch/auto/IP/World/World.bs') cc -shared -L/usr/local/lib -o blib/arch/auto/IP/World/World.so lib/IP/ World.o Copying lib/IP/World.pod -> blib/lib/IP/World.pod Copying script/ip_world_dump -> blib/script/ip_world_dump Changing sharpbang in blib/script/ip_world_dump to /usr/local/bin/ perlDeleting blib/script/ip_world_dump.bak Copying script/maint_ip_world_db -> blib/script/maint_ip_world_db Changing sharpbang in blib/script/maint_ip_world_db to /usr/local/bin/ perlDeleting blib/script/maint_ip_world_db.bak Copying script/ip_cc_benchmark -> blib/script/ip_cc_benchmark Changing sharpbang in blib/script/ip_cc_benchmark to /usr/local/bin/ perlDeleting blib/script/ip_cc_benchmark.bak Copying lib/auto/IP/World/ipworld.le -> blib/lib/auto/IP/World/ ipworld.dat Checking for database update (may rebuild)... Writing config notes to blib/lib/IP/World/ConfigData.pm t/0check_scripts.t .. 1..4 ok 1 - script/ip_world_dump syntax OK <SNIPPED LOTS OF TEST OUTPUT> ok 6 - blib/lib/IP/World/ConfigData.pm ok All tests successful. Files=5, Tests=439, 1 wallclock secs ( 0.09 usr 0.06 sys + 0.52 cusr 0.08 csys = 0.75 CPU) Result: PASS animalhead:/build/IP-World $ ll blib/libdoc ls: blib/libdoc: No such file or directory animalhead:/build/IP-World $ sudo ./Build install Building IP-World Manifying blib/lib/IP/World.pod -> blib/libdoc/IP::World.3 Manifying blib/lib/IP/World/ConfigData.pm -> blib/libdoc/ IP::World::ConfigData.3 Files found in blib/arch: installing files in blib/lib into architecture dependent library tree Skipping /usr/local/lib/perl5/site_perl/5.10.1/i386-freebsd/auto/IP/ World/World.bs (unchanged) Skipping /usr/local/lib/perl5/site_perl/5.10.1/i386-freebsd/auto/IP/ World/World.so (unchanged) Skipping /usr/local/lib/perl5/site_perl/5.10.1/i386-freebsd/IP/ World.pm (unchanged) Skipping /usr/local/lib/perl5/site_perl/5.10.1/i386-freebsd/IP/ World.pod (unchanged) Skipping /usr/local/lib/perl5/site_perl/5.10.1/i386-freebsd/IP/World/ ConfigData.pm (unchanged) Skipping /usr/local/lib/perl5/site_perl/5.10.1/i386-freebsd/auto/IP/ World/ipworld.dat (unchanged) Skipping /usr/local/share/man/man3/IP::World.3 (unchanged) Skipping /usr/local/share/man/man3/IP::World::ConfigData.3 (unchanged) Skipping /usr/local/bin/ip_world_dump (unchanged) Skipping /usr/local/bin/maint_ip_world_db (unchanged) Skipping /usr/local/bin/ip_cc_benchmark (unchanged) Writing /usr/local/lib/perl5/site_perl/5.10.1/i386-freebsd/auto/IP/ World/.packlist animalhead:/build/IP-World $ ll blib/libdoc total 20 -rw-r--r-- 1 root wheel 10728 Feb 18 00:15 IP::World.3 -rw-r--r-- 1 root wheel 7103 Feb 18 00:15 IP::World::ConfigData.3 animalhead:/build/IP-World $ ./Build distclean Cleaning up build files Deleting lib/IP/World.o Deleting blib/arch/auto/IP/World/World.bs Deleting blib/arch/auto/IP/World/World.so Deleting lib/IP/World.c Deleting blib cannot unlink file for blib/libdoc/IP::World.3: Permission denied at / usr/local/lib/perl5/5.10.1/Module/Build/Base.pm line 4868 cannot restore permissions to 0100644 for blib/libdoc/IP::World.3: Permission denied at /usr/local/lib/perl5/5.10.1/Module/Build/Base.pm line 4868 cannot unlink file for blib/libdoc/IP::World::ConfigData.3: Permission denied at /usr/local/lib/perl5/5.10.1/Module/Build/Base.pm line 4868 cannot restore permissions to 0100644 for blib/libdoc/ IP::World::ConfigData.3: Permission denied at /usr/local/lib/ perl5/5.10.1/Module/Build/Base.pm line 4868 cannot remove directory for blib/libdoc: Directory not empty at /usr/ local/lib/perl5/5.10.1/Module/Build/Base.pm line 4868 cannot remove directory for blib: Directory not empty at /usr/local/ lib/perl5/5.10.1/Module/Build/Base.pm line 4868 Couldn't remove 'blib': Directory not empty animalhead:/build/IP-World $
  Thu Feb 18 08:56:42 2010 dagolden [...] cpan.org - Correspondence added
Subject: Re: [rt.cpan.org #54740] Manifying not done during ./Build test
Date: Thu, 18 Feb 2010 08:55:07 -0500
To: bug-Module-Build [...] rt.cpan.org
From: David Golden <dagolden [...] cpan.org>
On Thu, Feb 18, 2010 at 3:44 AM, craig@animalhead.com via RT <bug-Module-Build@rt.cpan.org> wrote: Show quoted text
> The following log shows a sneaky problem with Module::Build. > > If I do the following 3 steps: >      perl Build.PL >      ./Build test >      sudo ./Build install > > the following 2 steps don't happen until the install operation: > > Manifying blib/lib/IP/World.pod -> blib/libdoc/IP::World.3 > Manifying blib/lib/IP/World/ConfigData.pm -> blib/libdoc/ > IP::World::ConfigData.3
It's not sneaky at all. "Build test" does not create documentation files because the "test" action doesn't depend on documentation. The proper incantation is: perl Build.PL ./Build ./Build test sudo ./Build install -- David
  Thu Feb 18 08:56:46 2010 The RT System itself - Status changed from 'new' to 'open'
  Thu Feb 18 12:41:56 2010 craig [...] animalhead.com - Correspondence added
Subject: Re: [rt.cpan.org #54740] Manifying not done during ./Build test
Date: Thu, 18 Feb 2010 09:40:53 -0800
To: bug-Module-Build [...] rt.cpan.org
From: craig [...] animalhead.com
IMO, not using the standard incantation should not result in insufficient permission errors when trying to clean up afterward. "Everyone knows" that "make test includes make if necessary". If time and my laziness permitted, I bet I could find lot of examples in online documentation, in which a command sequence skips from perl _.PL to _ test, for _ in (make, Build). 'the "test" action doesn't depend on documentation'. Hmmm. Your point implies that 'the "build" action depends on documentation', and the semantics of this escape me. Using normal English, I'd say that 'the "install" action depends on documentation', in the sense 'now that I've got this thing, how do I use it?'. Please live up to "make test includes make if necessary" by including all of the actions in './Build' in './Build test'. Presumably all of the actions only do what's necessary, and such inclusion will forestall problems like this from being reported to you guys how many times in the future? Best Regards, cmac On Feb 18, 2010, at 5:56 AM, David Golden via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=54740 > > > On Thu, Feb 18, 2010 at 3:44 AM, craig@animalhead.com via RT > <bug-Module-Build@rt.cpan.org> wrote:
>> The following log shows a sneaky problem with Module::Build. >> >> If I do the following 3 steps: >> perl Build.PL >> ./Build test >> sudo ./Build install >> >> the following 2 steps don't happen until the install operation: >> >> Manifying blib/lib/IP/World.pod -> blib/libdoc/IP::World.3 >> Manifying blib/lib/IP/World/ConfigData.pm -> blib/libdoc/ >> IP::World::ConfigData.3
> > It's not sneaky at all. "Build test" does not create documentation > files because the "test" action doesn't depend on documentation. The > proper incantation is: > > perl Build.PL > ./Build > ./Build test > sudo ./Build install > > -- David
  Fri Feb 19 02:53:18 2010 schwern [...] pobox.com - Correspondence added
Subject: Re: [rt.cpan.org #54740] Manifying not done during ./Build test
Date: Thu, 18 Feb 2010 23:52:19 -0800
To: bug-Module-Build [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
craig@animalhead.com via RT wrote: Show quoted text
> IMO, not using the standard incantation should not result > in insufficient permission errors when trying to clean up > afterward. "Everyone knows" that "make test includes make > if necessary".
If everyone knows that, everyone is wrong. Presuming by 'make' you mean MakeMaker/Makefile.PL. It acts like Module::Build. It does what is known as a "pure_all" which does not build the documentation... because it isn't necessary to run the tests. I hear your reasoning about users skipping the explicit build/make step, I do it all the time, but it isn't a new thing to Module::Build. I presume its a historical performance optimization, back when building documentation was expensive. Even with faster machines, I'd weigh keeping the build process slim (consider all the CPAN testers machines out there) more important than occasionally having to run "sudo make clean". -- I am somewhat preoccupied telling the laws of physics to shut up and sit down. -- Vaarsuvius, "Order of the Stick" http://www.giantitp.com/comics/oots0107.html
  Fri Feb 19 06:19:14 2010 craig [...] animalhead.com - Correspondence added
Subject: Re: [rt.cpan.org #54740] Manifying not done during ./Build test
Date: Fri, 19 Feb 2010 02:57:18 -0800
To: bug-Module-Build [...] rt.cpan.org
From: craig [...] animalhead.com
I run all M::B steps other than install as myself, and install under sudo. If the docs step doesn't get done in the build (make) step because you skip it, and then docs doesn't get done in the test step (by policy), under M::B it happens in the install step. So M::B (or one of its minion modules) puts the man files in blib with root:wheel as owner. A future clean step will again by run as me, and will make many ugly complaints when it tries to delete blib. Since I have a "process_dat_files" subroutine, I was able to work around this problem by including the following in this sub: sub process_dat_files { my $self = shift; my $invoked = $self->invoked_action(); my $current = $self->current_action(); if ($current eq 'code') { <snip> # temporary until the M::B guys include docs in test if ($invoked eq 'test') {$self->depends_on('docs')} } } goto END; On Feb 18, 2010, at 11:53 PM, Michael G Schwern via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=54740 > > > craig@animalhead.com via RT wrote:
>> IMO, not using the standard incantation should not result >> in insufficient permission errors when trying to clean up >> afterward. "Everyone knows" that "make test includes make >> if necessary".
> > If everyone knows that, everyone is wrong. Presuming by 'make' you > mean > MakeMaker/Makefile.PL. It acts like Module::Build. It does what > is known as > a "pure_all" which does not build the documentation... because it > isn't > necessary to run the tests. > > I hear your reasoning about users skipping the explicit build/make > step, I do > it all the time, but it isn't a new thing to Module::Build. I > presume its a > historical performance optimization, back when building > documentation was > expensive. Even with faster machines, I'd weigh keeping the build > process > slim (consider all the CPAN testers machines out there) more > important than > occasionally having to run "sudo make clean".
END: But people have to reason through that the solution to the ugly errors is in fact "sudo make clean". This is scary and frustrating except to experts like yourself. Assuming that 9x% of all builds go through the install phase, the manify (docs) step is going to get run in some phase, and presumably it is protected against being run more than once. So including 'docs' in 'test' does not make the overall installation any fatter! Thanks for replying, cmac
  Fri Feb 19 06:26:07 2010 craig [...] animalhead.com - Correspondence added
Subject: Re: [rt.cpan.org #54740] Manifying not done during ./Build test
Date: Fri, 19 Feb 2010 02:57:18 -0800
To: bug-Module-Build [...] rt.cpan.org
From: craig [...] animalhead.com
I run all M::B steps other than install as myself, and install under sudo. If the docs step doesn't get done in the build (make) step because you skip it, and then docs doesn't get done in the test step (by policy), under M::B it happens in the install step. So M::B (or one of its minion modules) puts the man files in blib with root:wheel as owner. A future clean step will again by run as me, and will make many ugly complaints when it tries to delete blib. Since I have a "process_dat_files" subroutine, I was able to work around this problem by including the following in this sub: sub process_dat_files { my $self = shift; my $invoked = $self->invoked_action(); my $current = $self->current_action(); if ($current eq 'code') { <snip> # temporary until the M::B guys include docs in test if ($invoked eq 'test') {$self->depends_on('docs')} } } goto END; On Feb 18, 2010, at 11:53 PM, Michael G Schwern via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=54740 > > > craig@animalhead.com via RT wrote:
>> IMO, not using the standard incantation should not result >> in insufficient permission errors when trying to clean up >> afterward. "Everyone knows" that "make test includes make >> if necessary".
> > If everyone knows that, everyone is wrong. Presuming by 'make' you > mean > MakeMaker/Makefile.PL. It acts like Module::Build. It does what > is known as > a "pure_all" which does not build the documentation... because it > isn't > necessary to run the tests. > > I hear your reasoning about users skipping the explicit build/make > step, I do > it all the time, but it isn't a new thing to Module::Build. I > presume its a > historical performance optimization, back when building > documentation was > expensive. Even with faster machines, I'd weigh keeping the build > process > slim (consider all the CPAN testers machines out there) more > important than > occasionally having to run "sudo make clean".
END: But people have to reason through that the solution to the ugly errors is in fact "sudo make clean". This is scary and frustrating except to experts like yourself. Assuming that 9x% of all builds go through the install phase, the manify (docs) step is going to get run in some phase, and presumably it is protected against being run more than once. So including 'docs' in 'test' does not make the overall installation any fatter! Thanks for replying, cmac
  Fri Feb 19 07:17:49 2010 schwern [...] pobox.com - Correspondence added
Subject: Re: [rt.cpan.org #54740] Manifying not done during ./Build test
Date: Fri, 19 Feb 2010 04:16:06 -0800
To: bug-Module-Build [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
craig@animalhead.com via RT wrote: Show quoted text
> I run all M::B steps other than install as myself, and install > under sudo. > > If the docs step doesn't get done in the build (make) step > because you skip it, and then docs doesn't get done in the > test step (by policy), under M::B it happens in the install step. > > So M::B (or one of its minion modules) puts the man files > in blib with root:wheel as owner. A future clean step will > again by run as me, and will make many ugly complaints when > it tries to delete blib.
Yes, this is quite understood. It happens to me, too. Perhaps a simple work around is to just start doing "sudo build clean" by habit? Show quoted text
> END: But people have to reason through that the solution to the ugly > errors is in fact "sudo make clean". This is scary and frustrating > except to experts like yourself.
I hate to say this, because I hate when I'm told it, but I've honestly never had this reported before. And like I said, MakeMaker's always done it. Show quoted text
> Assuming that 9x% of all builds go through the install phase
I don't know if that's a good assumption given the amount of testing a distribution goes through both by the developers and by 3rd parties. I'm inclined to say leave it as is, but if you can gather evidence that this is a widespread problem then maybe its worth burning the extra cycles on. Maybe some googling for people asking questions? Show quoted text
> the manify (docs) step is going to get run in some phase, and presumably > it is protected against being run more than once. So including 'docs' > in 'test' does not make the overall installation any fatter!
-- Reality is that which, when you stop believing in it, doesn't go away. -- Phillip K. Dick
  Fri Feb 19 08:47:27 2010 kwilliams [...] cpan.org - Correspondence added
On Fri Feb 19 07:17:49 2010, schwern@pobox.com wrote: Show quoted text
> I'm inclined to say leave it as is, but if you can gather evidence that this > is a widespread problem then maybe its worth burning the extra cycles on.
I wouldn't support docs getting built in the 'test' phase. An alternate solution might be for the 'install' phase to detect when it's running under 'sudo' or and modify the ownership of the files in blib/ or something. But there are sure to be things we'll get wrong with that and I think we'll be patching for a long time to get it right. It's far far simpler to just run 'sudo Build clean' like Schwern suggested.
  Tue Feb 23 12:28:24 2010 enobacon [...] gmail.com - Correspondence added
Subject: Re: [rt.cpan.org #54740] Manifying not done during ./Build test
Date: Tue, 23 Feb 2010 09:27:19 -0800
To: bug-Module-Build [...] rt.cpan.org
From: Eric Wilhelm <enobacon [...] gmail.com>
# from Ken Williams via RT # on Friday 19 February 2010 05:47: Show quoted text
>An alternate solution might be for the 'install' phase to detect when > it's running under 'sudo' or and modify the ownership of the files in > blib/ or something.
It would make sense to detect sudo install and abort if any depends() actions were not satisfied, but we don't really have that level of abstraction where we can say whether an action is satisfied without running it. That said, it might be possible to refactor the few actions in question such that the up-to-date checks are performed outside of the the action itself. --Eric -- Peer's Law: The solution to the problem changes the problem. --------------------------------------------------- http://scratchcomputing.com ---------------------------------------------------
  Wed Mar 10 14:38:48 2010 dagolden [...] cpan.org - Severity Normal added
  Wed Mar 10 14:41:06 2010 dagolden [...] cpan.org - Subject changed from 'Manifying not done during ./Build test' to 'Build install under sudo creates blib files owned by root'
  Sun Dec 05 23:09:06 2010 dagolden [...] cpan.org - Severity Normal changed to Unimportant