perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: [apr] dropping Apache2/ subdir for APR::*
Date Sun, 14 Nov 2004 16:05:56 GMT
Radoslaw Zielinski wrote:
> Sorry for the delay, I couldn't make it sooner.
> Stas Bekman <> [03-11-2004 02:30]:
>>Radoslaw Zielinski wrote:
> [...]
>>>* It messes with @INC, changing the way it should be parsed.
>>>  Originally, if you see $inc_file/Foo/Bar/, you know it's the
>>>  Foo::Bar::Baz perl module.  Now, it's Foo::Bar::Baz *unless* Foo
>>>  equals to Apache2.  The only other module I know, which does it, is
>>>  Tk; it creates problems with automated dependency generators (at
>>>  least), besides being a hack.
>>it doesn't.
> Well, it (the MP_INST_APACHE2 hack) does: "use Apache2" adds an entry to
> @INC and other modules rely on it.

When saying "it doesn't" I was talking about the para below:

>>There is no Apache2::Apache::Server. There is Apache::Server. 
>>It's just one Apache2/ subdir (like there are many other special subdirs 
>>in @INC dirs). Shouldn't be too hard to get used to it.
> I don't know of any more but Tk's plugin directory.

Think user-installed local modules under ~foo/lib/perl

>>This whole issue is moot for users who have moved to mp2 and forgot that 
>>mp1 ever existed, which will be the case for 99% of users some time after 
>>2.0 is released and considered stable.
> And what should an average Joe Distributor do while both versions are in
> use...?

Good point. In which case mp2 will always have to go to Apache2/.

>>>* A sysadmin (or user) without Perl knowledge won't even be able to
>>>  build mp2 without MP_INST_APACHE2 (for installation in DESTDIR for
>>>  example), when an installation of mp1 already exists -- requires
>>>  ripping Makefile.PL with sharpened $EDITOR.  Yes, this Makefile.PL
>>>  can be patched (MP_SHUT_UP_AND_RUN=1 for example), but it's just one
>>>  of many.
>>I'm not following you on this one. What's the problem of passing 
>>MP_INST_APACHE2=1? You mean they actually need to know that they need to 
>>type that? But the error message tells them that already.
> No.  Maybe a "patch" will show it:
>   --- mod_perl-1.99_15-org/Makefile.PL    2004-08-24 18:33:21.035839248 +0200
>   +++ mod_perl-1.99_13/Makefile.PL        2004-08-24 18:34:24.406205488 +0200
>   @@ -151,7 +151,7 @@
>                    error "cannot install mod_perl/$VERSION on top of $vstring",
>                        "use MP_INST_APACHE2=1 option " .
>                         "or to force installation delete:\n $old_modperl_pm";
>   -                exit 1;
>   +#               exit 1;
>                }
>            }
>        }
> I want to build without MP_INST_APACHE2 and run make install with
> DESTDIR.  This is a minor example of problems with "Makefile.PL logic".
> Nevermind.

Good point again. We should support that. i.e. if DESTDIR is specified we 
shouldn't enforce MP_INST_APACHE2=1 unless we find mod_perl 1 installed at 

>>There are quite a few CPAN modules that deploy that technique. e.g. 
> It uses a 5KB Makefile.PL just for figuring the installation path and
> dependencies... :-/

True. My idea was to write a helper module and make it available on CPAN, 
so all other 3rd party modules can use that and have very simple 
Makefile.PL files. Notice that it also requires special arguments passed 
to Makefile.PL to handle the situation when both mp1 and mp2 are 
installed. So if the same API is not embraced by all other 3rd party 
modules it's going to be a pain.

>>>Full Apache2::* namespace.  Apache2::compat::Apache1 could provide
>>>Apache::*->Apache2::* aliases for compatible features and define custom
>>>Apache::* for the incompatible ones -- both types of applications could
>>>work in one interpreter.  That would leave place for A2::compat::A3, and
>>>maybe for Apache::compat::Apache2.  No hacks required.
>>If you dig under the hood, it's not simple at all. To start with how are 
>>you going to handle the fact that no module is loaded by default? And you 
>>certainly don't want to load 50 modules each coming with .so object, just 
> [1]
>>to support this aliasing feature. Or do you suggest to just alias the 
> Maybe I'm missing something.  I was thinking about just aliasing the
> namespaces.

It's a way more complicated than it seems to be at first sight. Search the 
dev list's archives for EazyLife to see some of the problems.

>>Second, quite a few methods have the same API name, but a totally 
>>different functionality. Please see lib/Apache/ starting from 
>>I can't see how the two can coexist.
>   $ cat MP2/ 
>   package MP2::Foo;
>   sub sf { print shift() . "::same\n"; }
>   sub df { print shift() . "::different\n"; }
>   1;
 > ...well, maybe in a smarter way.  Note, that this allows coexistence of
 > both mp1 and mp2 applications in one interpreter.

The problem is that mp1 and mp2 aren't fully compatible, and there is no 
way to make them so 100%, mainly. So you have a problem here. You can't 
run all mp1 and mp2 applications under the same interpreter. Again take a 
look at lib/Apache/ %overridable_mp2_api and read:

I think I've mentioned this already, I'm not disagreeing with you, 
Radoslaw, that I've wished there was a better way than what we have now. 
But if you really start implementing your proposal you will see that there 
are problems in your idea. And some of them might be the showstopper. You 
are more than welcome to prove me/us wrong with a concrete working code.

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message