> Stas> 99.9% of users do *not* need to use this workaround. So that > Stas> issue is moot if you ask me.
> Four out of my five biggest customers *will* need to have both > modperl1 and modperl2 in the same Perl installation tree on their > development machines, because they'll need to start looking at how to > port their work over, and they won't want to duplicate-install all the > other modules they use into two different Perl installations on one > box. I would like to support Randal's contention (if not his tone) that indeed, in real-world mod_perl commercial situations that I'm familiar with (say about 8), 80% of those real-world users will want to have both mod_perl 1 and mod_perl 2 installed concurrently due to the generally-accepted production practice of "if it ain't broke, don't fix it". By virtue of being actual mod_perl, they already have production mp1 installations. They will also want to be moving forward with leading, new releases for development of new systems, that is, mp2. In any case, Stas, I found myself frowning when you first put out that "99.9% not a problem" number, and given the testaments given here, we can at least say "everyone's just guessing" what the real number is. Perhaps Randal should be thanking Stas for the potential conflicts, as it's fair to say that consulting fees can increase from confusions and complications arising from the mp1/mp2 transition. I do believe it's uncontested that with common configurations and proposals, simulataneous mp1 and mp2 installations will not be straightforward. People committed to mod_perl system will muddle through without doubt. New users won't generally see issues regardless of which docs they read. Though people who say extra hurdles don't help the community much have a point. On the gripping hand, I've never thought of mod_perl setup and administration as very intuitive or inherently robust. People who figure it out at all are generally already a notch or two above <panders to the crowd here> and have learned to read documentation. As a result of mod_perl's multi-step setup, I've long been very careful during new mod_perl setups. For a number of years now, I've been using private installation trees such that 0% of my commercial clients will have any mp1/2 issues as they use private, snapshotted installation trees to achieve high stability and service isolation. My modern installations if fact, generally use scripts which download, unpack, build, and install private installations of Apache, mod_perl, librequest, HTML::Mason, and even Perl itself with hundreds of modules from CPAN installed, all into a self-contained directory tree. Config files, log/state files, and the docroot(s) go outside this tree. Without revolutions in the mod_perl/Apache/CPAN space, this "private installation" approach is one of the few likely to provide really stable, isolated concurrent instances of mod_perl. It should be noted that mod_perl is not the only "application server" to suffer this problem, and the same things should be done for python 2.x, the Java multiverse, and PHP 4/5 web/SOA instances whenever availability, isolation, maintainability, and testability matter. Disk space is cheap. For my part, I'd put forth that one acceptance criteria of whatever mp2 release approach is adopted should be "it should be hard to clobber an existing installation by being careless with an mp2 installation". Going forward, I'd ask the community to remain respectful, proposal and evidence-focused, with an eye rough consensus and working code. There have been both shining examples and dismal failures thus far in the discussion.
