Shapira, Yoav wrote:
That would be the ideal solution, but I doubt it. Henri ?
Does Henri (or do you, Henri, since you're reading this ;)) work for/with JPackage.org to generate RPMs?
I do preffer insisting on our layout and having a warning on the site
and
at startup if this is modified. But if Henri and other people preffer supporting FHS - I'm fine too, as long as we do define one FHS variant and attempt
to
prevent the fragmentation.
I'm with you: one layout.
With tomcat maturing (it's already mature), keeping a stable way to deploy, configure, and setup things is a significant consideration. We have a huge user base that gets troubled and annoyed (justifiably in some cases) when we introduce things like the conf/[engine name]/[host name] structure without warning or sufficient documentation. I'm not saying we were bad, I'm just giving an example.
So if we have to have FHS, which would be unfortunate, let's at least make sure it's one consistent variant and update our docs accordingly.
+1
The only reason to support FHS would be the fact that many Redhat distros will refuse to include anything that is not FHS ( that seems the reason qmail is not available in debian or redhat - their licence requires certain layout and operating mode ).
I would preffer redhat/fedora/etc users to get tomcat from the apache RPM, but some may like the convenience of having it on the install CDs.
And it may be an easier battle to require distros to use our own defined-FHS layout ( insted of N variants ) then convince them to use our non-FHS layout ( even if the later will be easier to support and more stable ). Even the first is hard, since it removes their ability to lock-in and control.
Costin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
