Bug #48037 for ExtUtils-Install: Both ExtUtils::MakeMaker and ExtUtils::Install install ExtUtils/Install.pm

Mon Jul 20 18:38:20 2009 MSCHILLI [...] cpan.org - Ticket created

Subject:

Both ExtUtils::MakeMaker and ExtUtils::Install install ExtUtils/Install.pm

If users install both ExtUtils::MakeMaker and ExtUtils::Install, they'll end up with this conflict: WARNING: File ... lib/perl5/5.10/ExtUtils/Install.pm is already owned by active package perl-ExtUtils-MakeMaker-6.44_01 WARNING: File ... lib/perl5/5.8/ExtUtils/Install.pm is already owned by active package perl-ExtUtils-MakeMaker-6.44_01 WARNING: File ... man/man3/ExtUtils::Install.3 is already owned by active package perl-ExtUtils-MakeMaker-6.44_01 WARNING: File ... man/man3/ExtUtils::Installed.3 is already owned by active package perl-ExtUtils-MakeMaker-6.44_01 WARNING: File ... man/man3/ExtUtils::Packlist.3 is already owned by active package perl-ExtUtils-MakeMaker-6.44_01 What's the reason that both modules install the same file?

Mon Jul 20 20:05:23 2009 schwern [...] pobox.com - Correspondence added

Subject:	Re: [rt.cpan.org #48037] Both ExtUtils::MakeMaker and ExtUtils::Install install ExtUtils/Install.pm
Date:	Mon, 20 Jul 2009 17:04:54 -0700
To:	bug-ExtUtils-Install [...] rt.cpan.org
From:	Michael G Schwern <schwern [...] pobox.com>

Michael_Schilli via RT wrote: Show quoted text

> If users install both ExtUtils::MakeMaker and ExtUtils::Install, they'll > end up with this conflict:

What tool is reporting this conflict? Looks like some rpm thing. Show quoted text

> WARNING: File ... lib/perl5/5.10/ExtUtils/Install.pm is > already owned by active package perl-ExtUtils-MakeMaker-6.44_01 > WARNING: File ... lib/perl5/5.8/ExtUtils/Install.pm is > already owned by active package perl-ExtUtils-MakeMaker-6.44_01 > WARNING: File ... man/man3/ExtUtils::Install.3 is already > owned by active package perl-ExtUtils-MakeMaker-6.44_01 > WARNING: File ... man/man3/ExtUtils::Installed.3 is > already owned by active package perl-ExtUtils-MakeMaker-6.44_01 > WARNING: File ... man/man3/ExtUtils::Packlist.3 is already > owned by active package perl-ExtUtils-MakeMaker-6.44_01 > > What's the reason that both modules install the same file?

MakeMaker depends on a fairly recent ExtUtils::Install. ExtUtils::Install depends on MakeMaker. In order to break this dependency loop MakeMaker ships with a copy of ExtUtils::Install and will only install it if your installed ExtUtils::Install is older than the one it ships with. It does not declare this dependency because it would cause the CPAN shell to go into a dependency loop. It does this with a couple other modules too: ExtUtils-Install, ExtUtils-Manifest, ExtUtils-Installed and ExtUtils-Command. For packaging you should have ExtUtils-MakeMaker depend on those packages and not install its own copies. Sorry if it makes autogeneration of binary packages difficult. -- "Clutter and overload are not an attribute of information, they are failures of design" -- Edward Tufte

Mon Jul 20 20:05:28 2009 The RT System itself - Status changed from 'new' to 'open'

Tue Jul 21 11:13:35 2009 MSCHILLI [...] cpan.org - Correspondence added

On Mon Jul 20 20:05:23 2009, schwern@pobox.com wrote: Show quoted text

> What tool is reporting this conflict? Looks like some rpm thing.

It's a package manager, similar to rpm. I guess that this problem occurs with all package managers, because having two packages installing the same files causes conflicts, if no precautions are taken. But it's not an unsolvable problem, and with the info you've provided, I think I got a solution: What's needed is a note that ExtUtils::Install 'patches' or 'enhances' ExtUtils::MakeMaker. So installing ExtUtils::MakeMaker without ExtUtils::Install is fine, but if ExtUtils::Install gets installed, it should take over ownership of the shared files. If ExtUtils::Install then gets deleted later, the package manager needs to reinstate the original files of ExtUtils::MakeMaker that got clobbered. All this is easy to accomplish with a decent package manager, can you confirm that that's how it works? Thanks for the detailed info you've provided, it really helped me understand the problem.

Tue Jul 21 11:46:46 2009 demerphq [...] gmail.com - Correspondence added

Subject:	Re: [rt.cpan.org #48037] Both ExtUtils::MakeMaker and ExtUtils::Install install ExtUtils/Install.pm
Date:	Tue, 21 Jul 2009 17:46:26 +0200
To:	bug-ExtUtils-Install [...] rt.cpan.org
From:	demerphq <demerphq [...] gmail.com>

2009/7/21 Michael_Schilli via RT <bug-ExtUtils-Install@rt.cpan.org>: Show quoted text

> Queue: ExtUtils-Install > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=48037 > > > On Mon Jul 20 20:05:23 2009, schwern@pobox.com wrote:

>> What tool is reporting this conflict? Looks like some rpm thing.

> > It's a package manager, similar to rpm. I guess that this problem occurs > with all package managers, because having two packages installing the > same files causes conflicts, if no precautions are taken. > > But it's not an unsolvable problem, and with the info you've provided, I > think I got a solution: What's needed is a note that ExtUtils::Install > 'patches' or 'enhances' ExtUtils::MakeMaker. > > So installing ExtUtils::MakeMaker without ExtUtils::Install is fine, but > if ExtUtils::Install gets installed, it should take over ownership of > the shared files. If ExtUtils::Install then gets deleted later, the > package manager needs to reinstate the original files of > ExtUtils::MakeMaker that got clobbered. > > All this is easy to accomplish with a decent package manager, can you > confirm that that's how it works? Thanks for the detailed info you've > provided, it really helped me understand the problem.

Thats basically how it works for any part of core. EUMM and EUI just take it a level further. The version in core should be used, unless an update is provided, either via a EUMM upgrade, or a specific upgrade of EUI alone. And you can assume that EUMM wont overwrite an EUI install that is later than its own copy. IOW, the ownership could change back and forth. You could install EUI alone, then later upgrade EUI with EUMM, and then later install EUI alone again. Etc. chers, Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"

Tue Jul 21 12:09:42 2009 schwern [...] pobox.com - Correspondence added

Subject:	Re: [rt.cpan.org #48037] Both ExtUtils::MakeMaker and ExtUtils::Install install ExtUtils/Install.pm
Date:	Tue, 21 Jul 2009 09:09:21 -0700
To:	bug-ExtUtils-Install [...] rt.cpan.org
From:	Michael G Schwern <schwern [...] pobox.com>

Michael_Schilli via RT wrote: Show quoted text

>> What tool is reporting this conflict? Looks like some rpm thing.

> > It's a package manager, similar to rpm. I guess that this problem occurs > with all package managers, because having two packages installing the > same files causes conflicts, if no precautions are taken. > > But it's not an unsolvable problem, and with the info you've provided, I > think I got a solution: What's needed is a note that ExtUtils::Install > 'patches' or 'enhances' ExtUtils::MakeMaker. > > So installing ExtUtils::MakeMaker without ExtUtils::Install is fine, but > if ExtUtils::Install gets installed, it should take over ownership of > the shared files. If ExtUtils::Install then gets deleted later, the > package manager needs to reinstate the original files of > ExtUtils::MakeMaker that got clobbered. > > All this is easy to accomplish with a decent package manager, can you > confirm that that's how it works? Thanks for the detailed info you've > provided, it really helped me understand the problem.

Emulating exactly what goes on in the CPAN install is not necessary. It does that because it has to build itself. Presumably these are binary packages and have no such problem. MakeMaker doesn't really want its own copy of ExtUtils::Install. It doesn't change it and will happily used a regularly installed EUI. Its only there to avoid a circular build-time dependency. I'd just make the binary package for ExtUtils-MakeMaker (with no copy of ExtUtils::Install in it) depend on ExtUtils-Install and leave it at that. -- On error resume stupid

Tue Jul 21 12:58:49 2009 demerphq [...] gmail.com - Correspondence added

Subject:	Re: [rt.cpan.org #48037] Both ExtUtils::MakeMaker and ExtUtils::Install install ExtUtils/Install.pm
Date:	Tue, 21 Jul 2009 18:58:30 +0200
To:	bug-ExtUtils-Install [...] rt.cpan.org
From:	demerphq <demerphq [...] gmail.com>

2009/7/21 Michael G Schwern via RT <bug-ExtUtils-Install@rt.cpan.org>: Show quoted text

> Queue: ExtUtils-Install > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=48037 > > > Michael_Schilli via RT wrote:

>>> What tool is reporting this conflict? Looks like some rpm thing.

>> >> It's a package manager, similar to rpm. I guess that this problem occurs >> with all package managers, because having two packages installing the >> same files causes conflicts, if no precautions are taken. >> >> But it's not an unsolvable problem, and with the info you've provided, I >> think I got a solution: What's needed is a note that ExtUtils::Install >> 'patches' or 'enhances' ExtUtils::MakeMaker. >> >> So installing ExtUtils::MakeMaker without ExtUtils::Install is fine, but >> if ExtUtils::Install gets installed, it should take over ownership of >> the shared files. If ExtUtils::Install then gets deleted later, the >> package manager needs to reinstate the original files of >> ExtUtils::MakeMaker that got clobbered. >> >> All this is easy to accomplish with a decent package manager, can you >> confirm that that's how it works? Thanks for the detailed info you've >> provided, it really helped me understand the problem.

> > Emulating exactly what goes on in the CPAN install is not necessary. It does > that because it has to build itself. Presumably these are binary packages and > have no such problem. > > MakeMaker doesn't really want its own copy of ExtUtils::Install. It doesn't > change it and will happily used a regularly installed EUI. Its only there to > avoid a circular build-time dependency. > > I'd just make the binary package for ExtUtils-MakeMaker (with no copy of > ExtUtils::Install in it) depend on ExtUtils-Install and leave it at that.

EUI depends on EUMM tho. Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"

Tue Jul 21 14:47:13 2009 schwern [...] pobox.com - Correspondence added

Subject:	Re: [rt.cpan.org #48037] Both ExtUtils::MakeMaker and ExtUtils::Install install ExtUtils/Install.pm
Date:	Tue, 21 Jul 2009 11:46:53 -0700
To:	bug-ExtUtils-Install [...] rt.cpan.org
From:	Michael G Schwern <schwern [...] pobox.com>

demerphq via RT wrote: Show quoted text

>> I'd just make the binary package for ExtUtils-MakeMaker (with no copy of >> ExtUtils::Install in it) depend on ExtUtils-Install and leave it at that.

> > EUI depends on EUMM tho.

Hopefully rpm has some way to deal with circular run-time dependencies. Presumably you can just install them at the same time. Much better than having them play ping-pong with the ownership of lib/ExtUtils/Install.pm. -- 54. "Napalm sticks to kids" is *not* a motivational phrase. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/

Wed Jul 22 02:41:26 2009 m [...] perlmeister.com - Correspondence added

CC:	MSCHILLI [...] cpan.org
Subject:	Re: [rt.cpan.org #48037] Both ExtUtils::MakeMaker and ExtUtils::Install install ExtUtils/Install.pm
Date:	Tue, 21 Jul 2009 23:40:29 -0700 (PDT)
To:	demerphq via RT <bug-ExtUtils-Install [...] rt.cpan.org>
From:	Mike Schilli <m [...] perlmeister.com>

On Tue, 21 Jul 2009, demerphq via RT wrote: Show quoted text

> EUI depends on EUMM tho.

So you guys have a circular dependency. may I ask why you're not simply putting the code into one package/distro? Sure, you'll take a small hit regarding shared maintenance, but all the package managers out there that can't handle circular dependencies (CPAN.pm included last time I checked) will benefit. -- Mike Mike Schilli m@perlmeister.com

Wed Jul 22 02:49:11 2009 m [...] perlmeister.com - Correspondence added

CC:	MSCHILLI [...] cpan.org
Subject:	Re: [rt.cpan.org #48037] Both ExtUtils::MakeMaker and ExtUtils::Install install ExtUtils/Install.pm
Date:	Tue, 21 Jul 2009 23:48:00 -0700 (PDT)
To:	Michael G Schwern via RT <bug-ExtUtils-Install [...] rt.cpan.org>
From:	Mike Schilli <m [...] perlmeister.com>

On Tue, 21 Jul 2009, Michael G Schwern via RT wrote: Show quoted text

> Emulating exactly what goes on in the CPAN install is not necessary. > It does that because it has to build itself. Presumably these are > binary packages and have no such problem.

Problem is that creating a binary package is commonly done in an automated fashion (who wants to hand-edit thousands of CPAN modules) and if ExtUtils::MakeMaker installs a .pm file, it'll end up in the binary package in most cases. Now, I'm not saying it's not possible to make an exception and treat ExtUtils::MakeMaker in a special way. But it would be nicer if it didn't require it. -- Mike Mike Schilli m@perlmeister.com

Wed Jul 22 03:42:58 2009 demerphq [...] gmail.com - Correspondence added

Subject:	Re: [rt.cpan.org #48037] Both ExtUtils::MakeMaker and ExtUtils::Install install ExtUtils/Install.pm
Date:	Wed, 22 Jul 2009 09:42:40 +0200
To:	bug-ExtUtils-Install [...] rt.cpan.org
From:	demerphq <demerphq [...] gmail.com>

2009/7/22 Mike Schilli via RT <bug-ExtUtils-Install@rt.cpan.org>: Show quoted text

> Queue: ExtUtils-Install > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=48037 > > > On Tue, 21 Jul 2009, demerphq via RT wrote: >

>> EUI depends on EUMM tho.

> > So you guys have a circular dependency. may I ask why you're not simply > putting the code into one package/distro?

There is no circular dependency since BOTH MUST be installed with your default perl as well. Show quoted text

> Sure, you'll take a small hit regarding shared maintenance, but all the > package managers out there that can't handle circular dependencies > (CPAN.pm included last time I checked) will benefit.

EUI is smaller, and has at times been released out of sync with EUMM. Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"

Wed Jul 22 06:30:35 2009 dagolden [...] cpan.org - Correspondence added

Subject:	Re: [rt.cpan.org #48037] Both ExtUtils::MakeMaker and ExtUtils::Install install ExtUtils/Install.pm
Date:	Wed, 22 Jul 2009 06:29:38 -0400
To:	bug-ExtUtils-Install [...] rt.cpan.org
From:	David Golden <dagolden [...] cpan.org>

It seems to me that the "answer" should be for binary package of ExtUtils::MakeMaker to exclude the ExtUtils::Install files, but for the binary package to depend on a sufficiently high version of the binary package of ExtUtils::Install. I think that just requires excluding inc/ from PMLIBDIRS and adding those modules to PREREQ_PM if building a binary package. (Via argument or environment variable) David

Wed Jul 22 13:04:11 2009 m [...] perlmeister.com - Correspondence added

CC:	MSCHILLI [...] cpan.org
Subject:	Re: [rt.cpan.org #48037] Both ExtUtils::MakeMaker and ExtUtils::Install install ExtUtils/Install.pm
Date:	Wed, 22 Jul 2009 10:02:32 -0700 (PDT)
To:	demerphq via RT <bug-ExtUtils-Install [...] rt.cpan.org>
From:	Mike Schilli <m [...] perlmeister.com>

On Wed, 22 Jul 2009, demerphq via RT wrote: Show quoted text

> There is no circular dependency since BOTH MUST be installed with your > default perl as well.

You're talking about .pm files, I'm talking about cpan distributions. Show quoted text

> EUI is smaller, and has at times been released out of sync with EUMM.

Syncing your releases is the (small) hit you would have to take. -- Mike Mike Schilli m@perlmeister.com

Wed Jul 22 13:22:30 2009 dagolden [...] cpan.org - Correspondence added

On Wed Jul 22 13:04:11 2009, m@perlmeister.com wrote: Show quoted text

> You're talking about .pm files, I'm talking about cpan distributions.

We know. This is not a circular dependency issue, it's a bootstrapping issue, and it's only an issue for those who attempt to upgrade certain dual-life modules (i.e. .pm files) at the base of the toolchain using binary distribution packages. Binary distribution package managers have an impedence mismatch with source-based installation because they assume no dynamic configuration is necessary, and the CPAN toolchain is fundamentally based on dynamic configuration. C.f. "dynamic_config" flag in the META.yml specification -- which I suspect most binary packagers ignore completely. Show quoted text

> > EUI is smaller, and has at times been released out of sync with EUMM.

> > Syncing your releases is the (small) hit you would have to take.

The frequency of update and bug fix is different on each. It's not necessarily a small hit to coordinate and it's an ongoing hit. As I pointed out, the "fix" is to have binary packagers exclude any *.pm file in inc/ and capture the dependency in binary package prerequisites. -- David

Wed Jul 22 17:09:38 2009 schwern [...] pobox.com - Correspondence added

Subject:	Re: [rt.cpan.org #48037] Both ExtUtils::MakeMaker and ExtUtils::Install install ExtUtils/Install.pm
Date:	Wed, 22 Jul 2009 14:09:06 -0700
To:	bug-ExtUtils-Install [...] rt.cpan.org
From:	Michael G Schwern <schwern [...] pobox.com>

Mike Schilli via RT wrote: Show quoted text

> On Tue, 21 Jul 2009, Michael G Schwern via RT wrote: >

>> Emulating exactly what goes on in the CPAN install is not necessary. >> It does that because it has to build itself. Presumably these are >> binary packages and have no such problem.

> > Problem is that creating a binary package is commonly done in an > automated fashion (who wants to hand-edit thousands of CPAN modules) and > if ExtUtils::MakeMaker installs a .pm file, it'll end up in the binary > package in most cases. > > Now, I'm not saying it's not possible to make an exception and treat > ExtUtils::MakeMaker in a special way. But it would be nicer if it didn't > require it.

Its an exceptional situation, sorry. Fortunately its just one. Show quoted text

> So you guys have a circular dependency. may I ask why you're not simply > putting the code into one package/distro?

Good question. They were in the same dist. It was split out for a number of reasons. The biggest one being that MakeMaker is not the only thing which uses ExtUtils::Install. Module::Build does as well. This removes MakeMaker's privileged status wrt ExtUtils::Install and allows it to become more generic and levels the playing field. Also upgrading MakeMaker is a relatively Big Deal. Upgrading ExtUtils::Install... not such a big deal. Finally, you don't want your new module installer (Module::Build) to depend on your old module installer (ExtUtils::MakeMaker). -- 151. The proper way to report to my Commander is "Specialist Schwarz, reporting as ordered, Sir" not "You can't prove a thing!" -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/

Fri Nov 13 11:59:01 2009 dolmen [...] cpan.org - Correspondence added

We also get conflicting .packlist files. In my envronment I have both EUMM 6.54 and EUI 1.54 which both claim EU::Install, EU::Installed and EU::Packlist. It's quite odd that the module that handles .packlist (ExtUtils::Packlist) is itself not clearly owned. -- Olivier Mengué - http://o.mengue.free.fr/

Sat Nov 14 12:23:58 2009 mschwern [...] cpan.org - Correspondence added

On Fri Nov 13 11:59:01 2009, DOLMEN wrote: Show quoted text

> We also get conflicting .packlist files.

Debian just throws out the .packlists. Given that they're not very useful in the first place, and you've got a perfectly fine package manager, that seems sensible. Show quoted text

> In my envronment I have both EUMM 6.54 and EUI 1.54 which both claim > EU::Install, EU::Installed and EU::Packlist.

Well, that's between you and your package manager. I'm going to reject this ticket as there's not much we can do about it upstream. Show quoted text

> It's quite odd that the module that handles .packlist > (ExtUtils::Packlist) is itself not clearly owned.

What do you mean? Yves maintains it as part of EUI, though nothing is really done with it because packlists blow.

Sat Nov 14 12:24:00 2009 mschwern [...] cpan.org - Status changed from 'open' to 'rejected'