[gentoo-dev] proposal: webapp.eclass (long)

[gentoo-dev] proposal: webapp.eclass (long)

[Max Kalika]

There was a discussion a while back about where and how to install
web-related applications.  As it is now, most webapps try to do some grep
magic to see where the apache/apache2 doc root is.  Why not consolidate all
this into an eclass with the following (very rough) design spec:


--BEGIN---------------------------------------------------------
inherit webapp

# The directory to install. Defaults to "${S}"
WEBAPP_SOURCE="/path/to/source/dir"

# Override which files to install relative to ${WEBAPP_SOURCE}.
# Allows files, and directories.  Defaults to all (unset).
WEBAPP_FILES="file1.php file2.cgi dir1 dir2/file3.html"

# Files to move to /etc/webapps/${PN} and link back so they
# can be taken into account via CONFIG_PROTECT.
# Defaults to none (unset).
WEBAPP_CONFIGS="file1.php dir/config.php"

# Whether or not this webapp contains CGIs. See below.
# I can see a few packages benefiting from this: e.g. xmltv, mailman
# nut, apcupsd.  Defaults to no (unset).
WEBAPP_CGI="yes"

# Path to a file contain other directives for the generated apache 
# configuration file.  Defaults to none (unset)
WEBAPP_EXTRA="${FILESDIR}/somefile.conf"

src_unpack()   nothing changes -- unpack as normal;
src_compile()  nothing changes -- should have nothing to compile;
src_install()  by default runs webapp_src_install()
pkg_postinst() by default runs webapp_pkg_postinst()
pkg_config()   by default runs webapp_pkg_config()


webapp_src_install() is the workhorse
  - copies ${WEBAPP_SOURCE} all together or the items specified under
    ${WEBAPP_FILES} to /usr/share/webapps/${PN}. (I believe /usr/share/web
    was mentioned as a target candidate as well)
  - copies anything in ${WEBAPP_CONFIG} to /etc/webapps/${PN} and links
back 
    to /usr/share/webapps/${PN}.  (Maybe /etc/web?)
  - generates a ${PN}.conf and places it into /etc/apache2/conf/modules.d
or 
    /etc/apache/conf/addon-modules (or both, depending on what exists).
  - the conf file may look something like:

  Alias /${PN}/ /usr/share/webapps/${PN}/
  <Directory /usr/share/webapps/${PN}>
    AllowOverride Limit
    Options Indexes FollowSymLinks # ExecCGI if ${WEBAPP_CGI}
    # contents of ${WEBAPP_EXTRA} if it exists
  </Directory>

webapp_pkg_postinst()
  - prints an einfo about running /var/db/pkg/${PF}/${PF}.ebuild config

webapp_pkg_config()
  - activates the $PN.conf file created by webapp_src_install()
----END---------------------------------------------------------


Again, this is all very rough and is probably missing important features.
Here's a sample ebuild that can take advantage of this eclass (there's
absolutely zero testing done because the said eclass is not yet
implemented).


--BEGIN-[net-www/myweb-0.10.ebuild]-----------------------------
inherit webapp

IUSE=""
DESCRIPTION="PHP scripts intended to manage MythTV from a web browser."
HOMEPAGE="http://www.mythtv.org/"
SRC_URI="http://www.mythtv.org/mc/${P}.tar.bz2"

LICENSE="GPL-2"
SLOT="0"
KEYWORDS="~x86"

RDEPEND="dev-db/mysql
	dev-php/mod_php"

src_install() {

	WEBAPP_CONFIGS="settings.php"
	webapp_src_install()

	dodoc README

}
----END---------------------------------------------------------

---max kalika
--max@lsit.ucsb.edu
-lsit systems administrator

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] proposal: webapp.eclass (long)

[Alex Veber]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 02 July 2003 20:35, Max Kalika wrote:
> There was a discussion a while back about where and how to install
> web-related applications.  As it is now, most webapps try to do some grep
> magic to see where the apache/apache2 doc root is.  Why not consolidate all
> this into an eclass with the following (very rough) design spec:
>
>
> --BEGIN---------------------------------------------------------
> inherit webapp
>
> # The directory to install. Defaults to "${S}"
> WEBAPP_SOURCE="/path/to/source/dir"
>
> # Override which files to install relative to ${WEBAPP_SOURCE}.
> # Allows files, and directories.  Defaults to all (unset).
> WEBAPP_FILES="file1.php file2.cgi dir1 dir2/file3.html"
>
> # Files to move to /etc/webapps/${PN} and link back so they
> # can be taken into account via CONFIG_PROTECT.
> # Defaults to none (unset).
> WEBAPP_CONFIGS="file1.php dir/config.php"
>
> # Whether or not this webapp contains CGIs. See below.
> # I can see a few packages benefiting from this: e.g. xmltv, mailman
> # nut, apcupsd.  Defaults to no (unset).
> WEBAPP_CGI="yes"
>
> # Path to a file contain other directives for the generated apache
> # configuration file.  Defaults to none (unset)
> WEBAPP_EXTRA="${FILESDIR}/somefile.conf"
>
> src_unpack()   nothing changes -- unpack as normal;
> src_compile()  nothing changes -- should have nothing to compile;
> src_install()  by default runs webapp_src_install()
> pkg_postinst() by default runs webapp_pkg_postinst()
> pkg_config()   by default runs webapp_pkg_config()
>
>
> webapp_src_install() is the workhorse
>   - copies ${WEBAPP_SOURCE} all together or the items specified under
>     ${WEBAPP_FILES} to /usr/share/webapps/${PN}. (I believe /usr/share/web
>     was mentioned as a target candidate as well)
>   - copies anything in ${WEBAPP_CONFIG} to /etc/webapps/${PN} and links
> back
>     to /usr/share/webapps/${PN}.  (Maybe /etc/web?)
>   - generates a ${PN}.conf and places it into /etc/apache2/conf/modules.d
> or
>     /etc/apache/conf/addon-modules (or both, depending on what exists).
>   - the conf file may look something like:
>
>   Alias /${PN}/ /usr/share/webapps/${PN}/
>   <Directory /usr/share/webapps/${PN}>
>     AllowOverride Limit
>     Options Indexes FollowSymLinks # ExecCGI if ${WEBAPP_CGI}
>     # contents of ${WEBAPP_EXTRA} if it exists
>   </Directory>
>
> webapp_pkg_postinst()
>   - prints an einfo about running /var/db/pkg/${PF}/${PF}.ebuild config
>
> webapp_pkg_config()
>   - activates the $PN.conf file created by webapp_src_install()
> ----END---------------------------------------------------------
>
>
> Again, this is all very rough and is probably missing important features.
> Here's a sample ebuild that can take advantage of this eclass (there's
> absolutely zero testing done because the said eclass is not yet
> implemented).
>
>
> --BEGIN-[net-www/myweb-0.10.ebuild]-----------------------------
> inherit webapp
>
> IUSE=""
> DESCRIPTION="PHP scripts intended to manage MythTV from a web browser."
> HOMEPAGE="http://www.mythtv.org/"
> SRC_URI="http://www.mythtv.org/mc/${P}.tar.bz2"
>
> LICENSE="GPL-2"
> SLOT="0"
> KEYWORDS="~x86"
>
> RDEPEND="dev-db/mysql
> 	dev-php/mod_php"
>
> src_install() {
>
> 	WEBAPP_CONFIGS="settings.php"
> 	webapp_src_install()
>
> 	dodoc README
>
> }
> ----END---------------------------------------------------------
>
> ---max kalika
> --max@lsit.ucsb.edu
> -lsit systems administrator
>
> --
> gentoo-dev@gentoo.org mailing list


ohh, I like it, I am working on ebuilds for ACID and its deps so ALL the 
ebuilds could use that eclass.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/AySX0Q5UUdinJT4RAqX2AKDaoILdqePeaF4MCxQguiEsBEv+VACgsOkm
QMaAvHaNpVpZPZvMLhWSKzE=
=ktKt
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] proposal: webapp.eclass (long)

[Dylan Carlson]

On Wed July 2 2003 1:35 pm, Max Kalika wrote:
> There was a discussion a while back about where and how to install
> web-related applications.  As it is now, most webapps try to do some grep
> magic to see where the apache/apache2 doc root is.  Why not consolidate
> all this into an eclass with the following (very rough) design spec:

I don't have a problem with this so long as it is appropriately named.  I 
would suggest 'apache-webapp.eclass' instead since there are other servers 
than apache that can do this.

Regards,
Dylan Carlson [absinthe@gentoo.org]
Developer, Java Lead -- Gentoo Linux
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] proposal: webapp.eclass (long)

[Max Kalika]

Quoting Dylan Carlson <absinthe@gentoo.org>:

> I don't have a problem with this so long as it is appropriately named.  I 
> would suggest 'apache-webapp.eclass' instead since there are other
> servers  than apache that can do this.

Would it make sense to consolidate functionality to this eclass for all of
Gentoo's webservers?  And since there's more than one web-server, should
there be a virtual/httpd that this thing can depend on?

---max kalika
--max@lsit.ucsb.edu
-lsit systems administrator

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] proposal: webapp.eclass (long)

[Donny Davies]

>Would it make sense to consolidate functionality to this eclass for all of
>Gentoo's webservers?  And since there's more than one web-server, should
>there be a virtual/httpd that this thing can depend on?

Virtual/httpd is a definate good idea.  Its in my buglist, but I
havent yet gotten around to adding the VIRTUAL and PROVIDE items.

To add one little thing to this eclass proposal -- could you maybe
just check the other proposals that were submitted, on this
mailing list and pick out any items that should also maybe be
in here?

I've also asked previously for ideas about any other additional
functions that the eclass should provide.  Since the cat is
totally out of the bag now, it might as well try to incorporate
all the best suggestions from all of the different contributers
so that nobody feels *totally* slighted on this issue, although
it may be a little late for that but life goes on.

            Donny

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] proposal: webapp.eclass (long)

[Dylan Carlson]

On Wed July 2 2003 6:47 pm, Max Kalika wrote:
> Quoting Dylan Carlson <absinthe@gentoo.org>:
> > I don't have a problem with this so long as it is appropriately named. 
> > I would suggest 'apache-webapp.eclass' instead since there are other
> > servers  than apache that can do this.
>
> Would it make sense to consolidate functionality to this eclass for all
> of Gentoo's webservers?  And since there's more than one web-server,
> should there be a virtual/httpd that this thing can depend on?
>

Mmm, no -- there's too much variability between Apache and other web 
servers, servlet engines & WARs, Zope, etc...  It's better to confine this 
to Apache, IMHO.

Cheers,
Dylan Carlson [absinthe@gentoo.org]
Developer, Java Lead -- Gentoo Linux
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] proposal: webapp.eclass (long)

[Max Kalika]

Quoting Donny Davies <woodchip@gentoo.org>:

> To add one little thing to this eclass proposal -- could you maybe
> just check the other proposals that were submitted, on this
> mailing list and pick out any items that should also maybe be
> in here?

The only other thing I saw after a very brief check was a get_docroot()
function from a now-removed apache.eclass.  With this new eclass it
shouldn't be needed anymore, but it is certainly welcome.

> I've also asked previously for ideas about any other additional
> functions that the eclass should provide.  Since the cat is
> totally out of the bag now, it might as well try to incorporate
> all the best suggestions from all of the different contributers
> so that nobody feels *totally* slighted on this issue, although
> it may be a little late for that but life goes on.

I'm more than willing to add any functionality that people need.  My main
reason for presenting this now is that I desperately need this for my work
as I want to have a very clean way of installing a lot of various web apps
on a new-and-soon-to-be-deployed web server.  But I can also drag the cat
back into the bag and keep all this local.  I have a nice treat to lure him
back in... promise! :-)

I took Dylan Carlson's request and implemented an apache-webapp.eclass file
and accompanying man page.  Please see:

  <http://68.6.36.243:81/chora/cvs.php/portage/eclass>

I'll be creating new webapp ebuilds which use this eclass and throwing them
on there for perusal.  Please understand that I need to do this anyway for
work, but if anyone finds these userful, maybe they could be integrated.
And just to throw another match on the fire -- would it make sense to
create a new 'net-webapp' category and moving things like horde*, and phpbb
in there?  Other things I'll be creating ebuilds for are:  webalizer,
php(post?)nuke, mnogosearch, horde-ingo, horde-passwd, horde-gollem, etc.

Please be gentle. :-)

---max kalika
--max@lsit.ucsb.edu
-lsit systems administrator

--
gentoo-dev@gentoo.org mailing list