Bugzilla Bug 157956

The following is the output of an autoclean performed after emerging
tomcat-5.5-20-r5 (I think the previous installation was -r2)

--- !empty dir /usr/share/tomcat-5.5/server/webapps
--- !empty dir /usr/share/tomcat-5.5/server/lib
<<<        dir /usr/share/tomcat-5.5/server/classes
--- !empty dir /usr/share/tomcat-5.5/server
--- !empty dir /usr/share/tomcat-5.5/lib
--- !empty dir /usr/share/tomcat-5.5/common/lib
--- !empty dir /usr/share/tomcat-5.5/common/i18n
<<<        dir /usr/share/tomcat-5.5/common/endorsed
<<<        dir /usr/share/tomcat-5.5/common/classes
--- !empty dir /usr/share/tomcat-5.5/common
--- !empty dir /usr/share/tomcat-5.5/bin
--- !empty dir /usr/share/tomcat-5.5


The common/endorsed, common/classes, and server/classes directories are part of
the standard tomcat layout.

As they are being removed by autoclean/unemerge it may cause applications to
fail if they try to read the directory. A .keep file may be sufficient to keep
the directories from being removed.

Should be a matter of doing keepdir on the directories to keep during
src_install.

I just download a binary of Tomcat 5.5.20. In common, there is only lib and
i8n, no empty classes dir. There is no endorsed dir either since that is used
to for the 1.4 compat jars. If you download that package. In server there is
only lib and webapps per upstream binary.

Closing this bug because it's invalid. Not to sure how those dirs were created
or why they were removed. No changes in the -r* of the ebuilds effected that.
Or should effect that.

The release notes document the use of the directories, even though they comment
that they are "not created by default". The directories may be created by a
compilation and removed just for the bin distribution.

http://tomcat.apache.org/tomcat-5.5-doc/RELEASE-NOTES.txt

http://tomcat.apache.org/tomcat-5.5-doc/class-loader-howto.html

Those dirs are not present if someone unpacks a binary tomcat. Thus they will
not be present with the ebuild provided Tomcat. Just as you would have to
create them with a binary, you create them with the compiled from source
Tomcat. They are hardly used, and FYI do not exist at all with Tomcat 6.x.

Marked invalid before as it was, but I can mark wont fix if that will make you
happy. I can't take and implement all users requests. More so when it deviates
from what upstream provides or is available by default.

So going back to invalid, next will be wontfix. I can see no reason to have
those dirs created or present by default. Not looking to introduce any new bugs
to a stable ebuild to create empty potentially used dirs. 

Wow, sorry for upsetting you.

At first I merely wondered why directories which were created as empty by the
source compilation were not included by Gentoo. The directories are used by the
class loader and are the endorsed standard extension points for internal Tomcat
activities. http://tomcat.apache.org/tomcat-5.5-doc/class-loader-howto.html

I am not sure what Gentoo's policy is on extension directories, but the fact
that the directories can and will be searched by Tomcat to see whether it needs
to void one of its other classes is enough of a reason to keep.

Also not sure how this suddenly makes the ebuild "not stable". This is not an
extensive problem, and can easily be fixed by introducing some keep dir's.

I also did not know that Gentoo even cared what was in binary distributions,
knowing that everything must be compiled from source. Using a binary
distribution as a reason to change what is compiled by default would be a new
reason to me.

And, this is not Tomcat 6.x. The directories are still the ones which are used
by the class loader. I realise that Gentoo does not currently have any
Tomcat-based applications, and hence it won't notice the difference, it may be
more prudent to keep rather than stubbornly say you "wont-fix" the problem.

Created an attachment (id=103902) [edit]
The 3 line patch to keep the directories as standard extension directories

If someone cares to fix the bug, this is the patch. Quite simple really for all
the fuss it seems to have caused.

Created an attachment (id=103906) [edit]
Properly fix both the keep dir, and an invisible problem

Sorry, last patch was not correct.

There is a use of ${CATALIA_HOME} (note misspelling) in the current ebuild
which does not cause problems as is, however, it is completely out of place.

Also, the use of TOMCAT_HOME was not standard throughout, ie, there was a
definition and then it was not used.

Well thanks for catching that stuff. FYI this is an inherited ebuild, not one I
wrote from scratch. I took it over about a year ago, because no one else was.
Now Tomcat 6.0.x is another story and that one is cleaner. From looking at the
history it seems TOMCAT_HOME was inherited from 5.0.x, possibly 5.0.27. So it's
been around quite some time, and not sure how long it's been unused.

As for the other typo. That line is likely not needed since common/lib is not
empty. Thus no need to do a keepdir. Although it's interesting it did not
produce an error. I will address both and commit as neither effects anything
the package installs or it's function. Little to no chance of breakage.

(In reply to comment #4)
> Those dirs are not present if someone unpacks a binary tomcat. Thus they will
> not be present with the ebuild provided Tomcat. Just as you would have to
> create them with a binary, you create them with the compiled from source
> Tomcat. They are hardly used, and FYI do not exist at all with Tomcat 6.x.
>

Just to note for the future that you should rmdir these empty directories if
the ebuild creates them but does not want to keep them installed.