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 attachment 103902 [details, diff] 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 attachment 103906 [details, diff] 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.
