Re^2: When cpan returns the dreaded "won't install without force"

As this is mine very first post here, please forgive any obvioius idiocies.

Having rather large Perl installations on both Win and Debian, I have a little experience with install errors (as well as perhaps more questions than answers).

For the evil spawn of Redmond, may I humbly suggest that the OP use the ActiveState version of Perl *first*, as that is precompiled for Win and the ppm's in general do not produce error messages, except for incompetent errors like two nodules putting READMEs into the same directory.

Some modules simply do not *compile* well under Win, and I have had enough problems with Strawberry to stop using it.

M'lady's orignial distress "wont install without force" is often enough in truth a statement that due to a missing dependency, it wont install *even with force* : It wont install at all.

For a CPAN module probably the best place to look may not be the logs or scrollback, which I have often found confusing, but rather the META.YML files in the/Build directories, which normally state dependencies, as well as the home pages of the modules often with more info than CPAN.

For ActiveState the basic info is in the PPM .tgz files, which must be snatched from the $TEMP directory before they are deleted - if they cannot install normally. The info is in a .PPD file. One can use a simple file manager like FAR or TOTAL COMMANDER to simply copy the internal files to the appropriate SITE/lib and binary directories (usually /bin or /SITE/bin

For Win users I would also recommend installing CYGWIN, as it should have all the binaries that CPAN typically looks for, was well as the MingW compiler needed for some modules - even some of ActiveStates. (Else Visual C)

As Cygwin has its own, and usually outdated Perl, I would rename the binary, and possibly the directories within it. And add its path into the Win environment. It may even be possible to totally update the Cygwin Perl using CPAN. It would certainly be more methodically pure than using tethered software such as ActiveState. (I pray RMS will forgive my sins...).

Also, some dependencies are not on CPAN and the module authors automatically assume that they are already installed. Some are even proprietary - Mathematica and RT come to mind.

Comment on Re^2: When cpan returns the dreaded "won't install without force"

Replies are listed 'Best First'.
Re^3: When cpan returns the dreaded "won't install without force" by marto (Cardinal) on Mar 29, 2013 at 10:15 UTC
"As this is mine very first post here, please forgive any obvioius idiocies." Welcome! "Some modules simply do not compile* well under Win, and I have had enough problems with Strawberry to stop using it."* Not all modules are supposed to compile under windows, if you have some examples of modules which don't compile 'well' I'd be happy to give them a try. I've been using Strawberry since it's Alpha/Beta releases and haven't experienced any serious issues. "For a CPAN module probably the best place to look may not be the logs or scrollback, which I have often found confusing, but rather the META.YML files in the/Build directories, which normally state dependencies, as well as the home pages of the modules often with more info than CPAN." Agreed, a great many (if not most) problems stem from the fact that people don't read the documentation for the module they're trying to install. I find that most moudules are good a listing their dependancies. "For Win users I would also recommend installing CYGWIN, as it should have all the binaries that CPAN typically looks for, was well as the MingW compiler needed for some modules - even some of ActiveStates. (Else Visual C) As Cygwin has its own, and usually outdated Perl, I would rename the binary, and possibly the directories within it. And add its path into the Win environment. It may even be possible to totally update the Cygwin Perl using CPAN. It would certainly be more methodically pure than using tethered software such as ActiveState. (I pray RMS will forgive my sins...)." I think for new or less experienced users throwing cygwin into this mix will do more harm than good, in that it'll cause more confusion than it will resolve issues. From my experience Strawberry comes with everything I need to develop with Perl on Windows. ActiveState allows you to install MinGW etc via `ppm MinGW`, note that they don't provide a 64 bit build. I've recently read that the ActiveState repos are falling behind in provinding modules, especially for the 64bit platform. As I don't use it I've not looked deeper into the situation myself. "Also, some dependencies are not on CPAN and the module authors automatically assume that they are already installed. Some are even proprietary - Mathematica and RT come to mind." There are non cpan dependancies with certain modules, each instance of this in my experience is detailed in the module doumentation. For various reasons some third party stuff will never be on cpan, for example where the perl module is a wrapper around a third party or propriatry libary. Thanks for your input. Update: fixed typos	[reply] [d/l]
Re^4: When cpan returns the dreaded "won't install without force" by kel (Sexton) on Mar 29, 2013 at 17:26 UTC
Many thanks for your warm welcome! One of the problems I had with Strawberry, admittedly a couple of years back was with DBD:Mysql. I had to dig up some obscure patch from umannitoba to get it to work. Not being a programmer - it certainly was a learning experience! I run Linux and XP here. Though I have run Linux on and off since version 0.9, and my interest in Perl began when I needed an interface between my local database and website. Thats when I found Strawberry problematic - because I had no clue as to what was supposed to be Linux specific! (And my solutions needed to be cross platform) ActiveState is great for getting things up and running, especially Win32 projects. However, as many of its modules do come with precompiled binaries, portability is suspect from the start. However I would not use it on projects destined for Linux. I have my Debian system for that. As long as my database conversion scripts work, the origin of the binaries is not an issue... There is also another problem with the ActiveState PPM system. The uwinnipeg PPM depository is apparently no longer there, and one of the major secondary repositories has been relocated, and apparently not in any hurry to get things back up. SO AS and one or two other small repos are the only sources, making choices rather limited for the ppm method, though in fairness, Active State CPAN and CPANP works perfectly fine for installing most modules in the 'correct' manner. Of particular annoyance is that you are not encouraged to make your own repos, and efforts are made to stop you from doing it with ppms. They come in like buggers, creating a directory in TEMP, downloading and installing the directory tree, and then deleting the .tgz source files. And everything in the directory. When using the GUI PPM, you cn download dozens of PPMs at a time, but there is an atrociously nasty wait time for each module is it 'processes HTML'. You can shut that off though, but the instructions for hacking the right module have disappeared from google. Ideally there should be a way to run BOTH. Perhaps AS as a Win system Perl, and Strawberry as the Perl in an XAMPP install, where it would be more comfortable with a Linux type environment - especially for server apps. Has anyone tried this? Is there a simple script to toggle between the two?	[reply]