perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Radoslaw Zielinski <>
Subject Re: [apr] dropping Apache2/ subdir for APR::*
Date Tue, 02 Nov 2004 13:15:54 GMT
Stas Bekman <> [02-11-2004 05:59]:
> Radoslaw Zielinski wrote:
>> Sorry for warming up old threads, but I think it's worth to be noted: if
>> the two versions are incompatible, the proper solution is a namespace
>> change; in this case: APR2::* hierarchy.

>> A pity it hasn't been done with Apache::* modules, the MP_INST_APACHE2 +
>> "use Apache2" hack is a real pain in the ass for the distributors (like
>> Linux distributions).
> As it was repeated many times here (my apologies if it's the first time 
> that you hear that), the reason for not embedding the version number in 
> the module name is because for most the user API doesn't change. So if 
> your module/app wants to support several generations of some other module, 
> whose API hasn't changed, you don't need to turn your code into a big mess.

-> [1]

> talking to myself: I think I should add this to the docs somewhere. I've 
> repeated that explanation quite a few times already.

Well, this explanation was quite obvious for me, so I didn't even check
the archives -- explaining why something is a PITA doesn't make it less
painful.  I thought that you introduced it without forseeing the future

> Radoslaw, please grep the archives for Apache2 (I believe) to find the 
> relevant threads (there were quite a few of those on both lists).

...but now I did some homework, and -- suprisingly -- you knew them:
Then Doug came up with the hackish approach:

Now why is it wrong?

* It relies upon changed @INC.  Another thing to be remembered about.
* 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.
* If the API wouldn't change, there would be no porting problems.  Even
  if mp2 is mostly backward-compatible, mp1 isn't forward-compatible; is
  it?  Now, there is no easy (automateable) way of discovering if the
  module works with mp1 or mp2, or for which version it was written for.
* You can't use both mp1 and mp2 applications in scope of a single
  "PerlModule Apache::compat" (if the mp2 application is Apache::compat
* "use Apache2" isn't mandatory, so (IIRC, when I checked last time)
  most of the mp-dependent code doesn't do it.  To patch, or not to
  patch?  To care, or to drop&forget?
* 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.
* Doug wrote: "xs modules will need Makefile.PL/#ifdef logic to work
  with both versions".  Well, from my expirience, if such a logic works
  in any not-so-weird case and doesn't require investigation / patching,
  it's accidental.  If you want both mp1 and mp2 on your system, you
  won't get away without all-the-hacks' know-how.
* ...well, I don't remember more right now.

All these issues boil down to one thing: you can't have mp1 and mp2 with
applications for both without using hacks.  You aimed for simplicity and
backward compatibility, but IMHO the result was reversed in this case.

How could it be avoided?

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.

About the [1] mess: I don't see any.  If you'd like your application to
work with both, you'd write for mp1 and require the appropiate compat
module to be loaded.  If something's missing, we'll see it at the
compilation stage, without wondering "does this method I'm using in this
rarely triggered case do the same thing under mp2 with Apache::compat?".

I just hope I don't repeat something already discussed.

Radosław Zieliński <>
[ GPG key: ]

View raw message