Re: [mp2] DESTDIR does not apply to mod_perl.so and includes

[prev] [thread] [next] [Date index for 2005/02/09]

> sure, but you can help us figure out a solution w/o knowing anything about
> mod_perl. The situation of the packagers is unique. One can think of it as
> if they are using chroot(1), where their / moves elsewhere. It'd be easy
> to make DESTDIR supported, but this is not the right thing. mod_perl has
> to be installed where all other Apache modules are. So DESTDIR must not
> affect it. Notice that unlike mp1, mp2 does not install mod_perl.so under
> the perl tree.

I understand that. Since the installer uses apxs to locate apache directory
(right?) it only makes sense on the system where it's being installed.

> I suppose the simplest solution to this problem is to provide a new
> Makefile.PL argument, which will be the same as DESTDIR in the perl world,
> but for Apache things. e.g., MP_AP_DESTDIR, so if specified it can be used
> exactly as in your patch above. (handling the trailing slash of ofcourse).
> In your case MP_AP_DESTDIR will be the same value as DESTDIR.

Yes we need to have a build of apache ready somewhere (with a proper apxs)
to build mod_perl anyway, there's no way that we could make the package
without it.

Still I'm not convinced about writing files outside the package tree ; whenever
DESTDIR is set I see it as 'please put your stuff in there so I can make a
package out of it'. Really depends on how the package maintainer wants it
done : either make an apache package with mod_perl.so then another package
with perl-related stuff, or make one package with both apache+mod_perl,
or keep apache as it is and make another package with both mod_perl.so
(and mod_perl includes), in, say, /usr/libexec/apache2, and perl stuff in
its right place. As far as I'm concerned I prefer the third option, as I
find more logic in not having a useless mod_perl.so in a plain apache package
(first option) and may want to install a simple build of apache with no bells+
whistles on some systems. For that purpose, seems to me DESTDIR should apply
to all involved packages.

Last I found very annoying when building that mod_perl.so should find its
way to some place in my root directory where it might have overridden some
other version of mod_perl that could have been in use...


[From your answer to Nick's...]
> > so my first reaction to your saying "So DESTDIR must not affect it" is
> > "that
> > doesn't follow". Hence asking what it actually does at the moment.
>
> DESTDIR is a perl thingy. It will send all perl bits to DESTDIR.
>
> mod_perl.so and its .h files are not perl thingies, and so DESTDIR doesn't
> apply here by design. Simply because Apache thingies live under the Apache
> tree, not the perl tree.

As far as I can see DESTDIR's becoming pretty standard and it is available
in Apache's Makefile so I wouldn't call it a perl thingy anymore... Yet I
understand your point as we have two packages here ; once again, the question
is, does it make sense to build a separate package for mod_perl or should we
(can we btw?) always build both mod_perl *and* apache at the same time ?
My answer is still not for me...

PHP is another example of a non-apache "thing" that puts a lib in apache's
tree (I believe every single program that also builds an apache module out
there is too). PHP doesn't have a DESTDIR at all though, they chose to call
it INSTALL_ROOT, well, fine, it has the same purpose. There is almost the
same issue there. PHP installs everything in INSTALL_ROOT, regardless of
whether it's a php thing or an apache thing (mod_php.so). However if you
use apxs from your root installation instead as the one you built as a
package you may get a different layout from the one you'd expect for your
package. That's for the distribution maintainer to care for however.

Thanks
F.