in reply to When cpan returns the dreaded "won't install without force"
I think that it certainly would be an improvement if the failed installation session would end with a synopsis of exactly why the process failed ... and if there were routinely a log or transcript. The output of any installation is extremely noisy.
However, it would not be particularly easy to do this, because packages vary in age as well as in the completeness of their designs, all of which are self-contributed by whomever owns the package (or owned it at the time). There is no single-standard. There’s even more than one module-building framework: when improvements to that process were introduced, package maintainers gradually over time (maybe) moved to it, but old packages that still work just fine were not re-written. The quality-assurance such as it is (and usually, it is just fine) is self-regulated by the CPAN community.
I have a few particular cases where the “won’t install without” scenario appears in some of the deployments that I maintain:
- One package requires a third-party C library, a standard one, but it assumes that the library exists. (Perhaps this is because there is no one single known-good way to check for it on all systems?) If it’s not there, you don’t get a prerequisite-error: you get a nasty failure to compile, with lots of oily parts on the runway when the whole thing finally skids to a stop on the tarmac.
- Another package is similar: the library has been updated and the package requires the newer one, but older deployments of it do exist out there.
- CPAN package re-designs have caused issues. You can design your package any way you want to. Someone else’s package, perhaps unbeknownst to you, uses a package feature that its owner now considers to be deprecated. Or a test-script in your installation sequence still refers to it. There is one package that I use which at this moment must be forced. (Sure, I offered a patch to the test.)
- Windows-environment users are very familiar with the scenario where they want to use a package that was written by a person who only has access to Linux or Unix, and who therefore is not in a position to make adjustments to suit other environments ... and there are a great many environments.
“Missing and unrealized prerequisites,” by-the-by, are a definite possibility to be dealt-with in the field. Success of an installation depends not only upon you correctly specifying all of the pre-requisites and co-requisites of your package, but that all of them have done the same and that they forever continue to do so. To some degree, manifests and so-forth are hand written. If a requisite is left-out but your system does have it, you don’t necessarily recognize the existence of the problem. On top of this, there are a few “co-dependency paradoxes” which actually oblige you to force installation of package A, in order that you can now install package B, in order that you can now properly re-install package A. You can see this clearly if you have to deal with a scenario that rarely occurs: installing a Perl application on an absolutely-naked system i.e. step #1 is compiling the Perl executable from scratch and so-on. And your task is to construct an absolutely hands-free installer/updater for that case. Attempt that, and you will find some amount of grief despite everyone else’s earnest efforts.