Bug #4093 for CPANPLUS: CPANPLUS doesn't take actual file location into account

Mon Oct 13 09:39:58 2003 jv [...] cpan.org - Ticket #4091: Ticket created

Subject:

DO not use sudo unless necessary

CPANPLUS 0.045 uses sudo to install files. However, it should only do this when necessary, i.e. when an ordinary user wants to install files in the (super-user owned) perl hierarchy. When installing files in a location that is owned (or otherwise modifyable) by the user, sudo should not be used (notwithstanding the fact that the user did answer 'yes' during configuration).

Mon Oct 13 16:03:29 2003 jv [...] cpan.org - Ticket created

Subject:

CPANPLUS doesn't take actual file location into account

To maintain a private library. the command line arguments LIB and PREFIX are passed to MakeMaker, as per documentation. However, CPANPLUS does not take this into account when checking. This results in the following errors: * If the right version of the module is already installed in the system Perl hierarchy, it requires --force to install it in the private library. * Uninstall fails, since it cannot find files to uninstall. See the attached and commented (>>>>) logfile for details. This file also contains the CPANPLUS config that was used.

Download cpp.log
application/octet-stream 9.4k

Message body not shown because it is not plain text.

Tue Oct 14 06:26:07 2003 kane [...] dwim.org - Ticket #4091: Correspondence added

Date:	Tue, 14 Oct 2003 12:26:23 +0200
Subject:	Re: [Cpanplus-bugs] [cpan #4091] DO not use sudo unless necessary
From:	"Jos I. Boumans" <kane [...] dwim.org>
To:	bug-CPANPLUS [...] rt.cpan.org
RT-Send-Cc:

On Monday, October 13, 2003, at 03:39 PM, Johan_Vromans via RT wrote: Show quoted text

> CPANPLUS 0.045 uses sudo to install files. However, it should only do > this when necessary, i.e. when an ordinary user wants to install files > in the (super-user owned) perl hierarchy. When installing files in a > location that is owned (or otherwise modifyable) by the user, sudo > should not be used (notwithstanding the fact that the user did answer > 'yes' during configuration).

i'm afraid i disagree, and this wholly from a pragmatic stance: CPANPLUS doesn't actually know /where/ you are installing to -- MakeMaker or module::build does. So some way, we'd have to pull out this information, check if all these locations are writable (what if some are and some aren't?) and then determine whether sudo is needed or not. In praxis, the configuration people choose is one of the following two: no makemakerflags + sudo makemakerflags + no sudo if you choose a mixture of the 2, there's still ways to turn it off from the shell and the API when you need it. Trying to do what we think might be what the user had really wanted (but maybe they wanted mmflags AND sudo?) is not something i'm willing to do. -- Jos Boumans "You know you are never more indignant in life than when you're shopping at a store you feel is beneath you and one of the other customers mistakes you for one of the employees of that store." - Dennis Miller CPANPLUS http://cpanplus.sf.net

Tue Oct 14 06:37:04 2003 kane [...] dwim.org - Correspondence added

Date:	Tue, 14 Oct 2003 12:37:20 +0200
Subject:	Re: [Cpanplus-bugs] [cpan #4093] CPANPLUS doesn't take actual file location into account
From:	"Jos I. Boumans" <kane [...] dwim.org>
To:	bug-CPANPLUS [...] rt.cpan.org
RT-Send-Cc:

On Monday, October 13, 2003, at 10:03 PM, Johan_Vromans via RT wrote: Show quoted text

> To maintain a private library. the command line arguments LIB and > PREFIX are passed to MakeMaker, as per documentation. However, > CPANPLUS does not take this into account when checking. This results > in the following errors:

correct -- we don't parse or try to understand any flags passed to makemaker -- we have our own way of expanding your @INC; * during configuration, you are asked to supply extra include directories * the 'e' command in the shell (which will disappear in 0.050 though) can be used to add directories to your @INC. If you save the config, this setting will now be applied every time you use cpanplus. Show quoted text

> * If the right version of the module is already installed in the > system Perl hierarchy, it requires --force to install it in the > private library.

I'm not sure this is a bug -- if a module is uptodate, we don't install it again. This is a design decision of CPANPLUS. And as you point out, there's a way to override it. I'm not sure how trivial it would be to understand you're trying to install into a private directory, since that again would mean parsing and understanding makemakerflags, which is not something i want to get into. Suggestions welcome though. Show quoted text

> * Uninstall fails, since it cannot find files to uninstall.

See above. -- Jos Boumans "Time is nature's way of making sure all the sh*t doesn't happen at once" CPANPLUS http://cpanplus.sf.net

Tue Oct 14 08:37:01 2003 jv [...] cpan.org - Correspondence added

From:

jvromans [...] squirrel.nl

I think for practical purposes, we can consider bug #4091 a duplicate of this one. The whole problem is that CPANPLUS does not know what MakeMaker or Module::Build will actually do. This is because the installation details are passed in (unprocessed) options to MakeMaker and Module::Build. As a result, CPANPLUS can not check if a given module is already installed in the actual location, and can not uninstall it from that location. Show quoted text

> I'm not sure how trivial it would be to understand you're trying to > install into a private directory, since that again would mean parsing > and understanding makemakerflags, which is not something i want to get > into. > Suggestions welcome though.

Instead if passing (and parsing) MakeMakefile / Module::Build flags, just give control to CPANPLUS. By adding a config setting to denote a private library, CPANPLUS can check this library for installed modules, and uninstall from this library. When calling MakeMaker or Module::Build, CPANPLUS can supply the right arguments to have them install in the right location.

Tue Oct 14 08:38:33 2003 jv [...] cpan.org - Ticket #4091: Correspondence added

See my remarks on bug 4093.

Mon Nov 03 07:30:00 2003 kane [...] cpan.org - Ticket #4091: Ticket 4091 MergedInto ticket 4093.

Tue Jun 29 08:29:20 2004 kane [...] cpan.org - Status changed from 'new' to 'resolved'