> 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.
