tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <r...@apache.org>
Subject Re: Fedora "tomcat"
Date Mon, 17 May 2004 16:01:56 GMT
Costin Manolache wrote:
> I'm fine with using jpackage as the "official" or recommended binary 
> distribution for RPM-based distributions. This solves part of the problem.
> 
> To make sure everyone understand, this will mean we support the 
> following layout for FHS-based linux systems, in addition to our
> typical layout:
> - config files in /etc/tomcat5/
> - logs in /var/log/tomcat5
> - workdir and tempdir in /var/cache/tomcat5/[temp/work]
> - webapps will be deployed on /var/lib/tomcat5/webapps
> - lib dirs under /var/lib/tomcat5/[commons/shared/server]
> - homedir and bin under {datadir}/tomcat5 ( not sure what datadir is, 
> Henri ? )
> - only tomcat files included, all other .jars will come from separate
> - dependent RPMs you need to install: ....  ( there seem to be 10+ )
> I am still unable to get jpackage installed via apt on fedora2 ( 6 
> dependent "not installable" ) - if I get it working I'll post the exact 
> paths and dependencies.
> 
> 
> This will be in addition to the normal layout most documentations and 
> books typically assume:
> - webapps in $CATALINA_HOME/webapps
> - config in $CATALINA_HOME/conf
> - longs in ../logs
> - a script called "catalina.sh" that takes the CATALINA_HOME env and 
> does a number of actions in certain way
> - ...
> 
> Should I make a proposal to make those 2 layouts "official" ? Is it ok 
> if we recommend the second layout to be used whenever possible - i.e. in 
> non-FHS-limited distributions ? Do we want to also define a default base 
>  dir - like /usr/local/tomcat5 or /opt/tomcat5 ( similar for 4 ) ?
> 
> I can write a .spec file to create a RPM in the second layout - and I'm 
> pretty sure I can integrate the building of the RPMs in the build.xml ( 
> cygwin can be used on windows to generate RPMs AFAIK - I need to try )
> My preference will be to at least include the second "full tomcat/easy 
> to install/same layout as on other OSes" non-FHS RPM in the release, 
> even if you don't agree to make it the default/recommended one.
> 
> 
> The main benefit is that people can then easily write scripts and 
> install files ( RPM, etc ) to easily deploy webapps or extensions, and 
> support will be much easier. At least they would have to maintain only 2 
> versions of their packages instead of one for each linux distro.
> 
> 
> The second big question is what do we do to promote this layout and 
> prevent fragmentation. Options:
> - include some text in the release notes or on the web page
> - add a piece of code that checks at runtime and display a strong 
> warning that people shouldn't use that package ( or shouldn't contact 
> tomcat for problems ). If someone removes this - it will become a 
> derivative work, so maybe we can use something in license.
> - place "don't use" links to RPMs/distros using non-standard layouts ?
> - add some Sun-like rules - pass the unit tests and basic load tests,
> don't remove things, use one of the recommended layouts - in order to 
> list the distro as "compatible" ?
> 
> Finally - am I overreacting, are other people seeing this as a real 
> issue, or should we just ignore the problem like apache does ?

I would answer no, as the stability issue is a big problem (the HTTPd 
doesn't have that issue; why is the worst left to us ? :/). The 
directory layout is a less critical issue.
(we can't do the last point: the license allows basically anything)

Rémy


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message