Bugzilla Bug 77778

gsweb-1.1.1_pre20050106 uses depend.apache which is great, but gsweb actually
is an apache module, so it should use apache-module eclass instead, and let the
eclass handle compiling (possibly) and installing the module and configuration
files.

If you choose not to use the apache-modules eclass, you should at least use the
variables available in depend.apache.eclass to install your module and
configuration to the right locations (the current gsweb ebuild does not).

Thanks!

Okay, can do.

However, out of these files gsweb installs into the apache layout:
/etc
/etc/apache2
/etc/apache2/conf
/etc/apache2/conf/modules.d
/etc/apache2/conf/modules.d/90_mod_gsweb.conf
/etc/apache2/conf/gsweb.conf
/usr
/usr/lib
/usr/lib/apache2-extramodules
/usr/lib/apache2-extramodules/mod_gsweb.so

...which are out of place?  The seemingly extra gsweb.conf file configures the module itself (rather than the module-for-apache, so to speak).  If installed most FHS-correctly, it should go into /etc/gsweb, most likely?

If anything else seems out of place, please also let me know, and I'll soon get to updating it to apache-module.eclass.  Thanks.

/etc/apache2/conf/modules.d/90_mod_gsweb.conf
should be in /etc/apache2/modules.d now

/etc/apache2/conf/gsweb.conf 
should be in /etc/gsweb, like you said, though I suppose /etc/apache2 would be acceptable, but not preferred (as it doesn't configurae apache)

/usr/lib/apache2-extramodules/mod_gsweb.so 
should be in /usr/lib/apache2/modules

but the apache-module eclass takes care of installing all of this for you.
just set APACHE2_MOD_FILE to the location of the module (without the .so), APACHE2_MOD_CONF to the location of the module configuration file, and APACHE2_MOD_DEFINE to the name you use in the module configuration with the IfDefine directive. apache-module will take care of installing and displaying necessary messages about enabling it.

if you don't want to override the src_compile, you probably also want to set APXS2_ARGS to include the -DLIB defintions the module needs, as well as any other .c files that need to be compiled, and the src_compile in the eclass will take care of building it for you.

ping. This is blocking apache from unmasking, what is the status?

I was out of commission for a bit, but now I'm back.

I need to upgrade this ebuild (as it depends on beign in sync with other packges from GNustep cvs), and update th ebuild as described  above too.

I'll respond again soon.

Okay, I've been battling this for a bit now, and I've finally making some
progress.

I don't mean to sound impudent, but, to me, it seems that apache-module.eclass
seems a bit naive.  Granted, I'm probably the only dev dealing with
ObjC/GNUstep madness, and I'll take that as "my problem" but....okay, here are
some of the annoyances that took me more time than they should have while
trying to use apache-module (and not depend.apache directly):
- expects .c files ... sure if there's 1 source file, it has to be a c file,
but there's no reason any of the supported GCC languages, C++ and ObjC
included, couldn't be included in other files (and linked appropriately...
which leads me to:
- no real support for multiple source files (although, if apache-module assumes
"simple modules", than this isn't really a problem, but that should be stated
at the top of the eclass -- as well as what env variables need to be set for
the eclass to work!)
- apu-config is annoying (which is my problem), but I'm not sure if it's able
to return all the information that is needed if one is not using
apache-module.eclass; scenario: I wrote a dummy ebuild that depended on
apache-module and ran apache-module_src_compile just so I could see what it was
trying to do -- it's outputting seemingly important -DOptions that I assume are
telling the being-compiled-module such things as what mpm support is in apache
or something (not claiming to be an apache god, mind you)...is there a tool
besides apu-config that can help me pass this into compile commands I'm
generating?  Or am I just missing something?

Anyways, I say all this 'cause I've been trying to debug why GSWeb is
segfaulting on me (yeah, I turned LogLevel up to debug), and it has to be
something with either libraries not getting linked in, or something
mis-built/configured apache support (gsweb's fault: i have no idea what mpm's
it supports) [The highest level debug gives me an interesting error where the
module is not getting what are internal requests from apache ... it seems]. 
However, GSWeb "used to work" wrt the old apache2 ebuilds.

Anyways, please don't misconstrue my irritation.  The new apache2 setup looks
damn impressive. :-)  If you have any pointers, concerning all this, please let
me know.  Now, for me, back to hacking on this...

- ebuild uses depend.apache.eclass, and not apache-module.eclass, as it is a
complex apache module
- depends on apache2
- GSWeb must load right after SSL (for now), as mod_php is screwing up its
alias handler, but not vice versa (and I dont use ldap or dav, atm)
(- mod_php-4.3.10-r1 should/can be marked ~ppc, btw)
- use of apr-config was needed as well as apu-config (apr-config --cppflags
provided, what I think, were the other key flags)
- big is fixed