You're getting this bug because the package in summary installs its documentation (or at least part of it) outside the usual /usr/share/doc/${PF} directory. First, please keep in mind that this bug might not be noticeable for -r0 ebuilds, but it might be for -r1 and later, since if the ebuild has same name and version of the package, for -r0 it might correspond properly. To fix this, if the package uses autotools, recent version (autoconf 2.61+) have two ./configure switches: --docdir and --htmldir to decide where to put the documentation. Older versions might require you override docdir/htmldir or other custom variables during make install. For non-autotooled build systems, good luck, since I cannot tell you how to achieve the proper results, the same holds true with totally broken buildsystems even when based on autotools. Thanks, Diego
Thx for the bug report. I am aware of this issue. It appears that Sourcefire has added a Makefile to their doc's directory which is causing the doc's to be "installed" twice: once in /usr/share/doc/${PF} and once in /usr/share/doc/snort. The /usr/share/doc/${PF} location is installed via the ebuild process and the other location is installed from the Makefile added by Sourcefire. I'm looking at options to prevent the install by the Makefile. I prefer to use the ebuild to install the docs because then they are compressed and the Makefile does not properly install all the doc's.
of course that was supposed to be snort and me I'm going to need more coffee during the day ;) At the least you could just remove the extra doc dir; but you should probably be able to skip entering that particular directory/makefile.
Is the proper bugs etiquette to submit/attach a fixed -r1 version of the ebuild to this bug or open a new bug for the new -r1 ebuild? I'm looking at(In reply to comment #2) > of course that was supposed to be snort and me I'm going to need more coffee > during the day ;) > > At the least you could just remove the extra doc dir; but you should probably > be able to skip entering that particular directory/makefile. >
I don't think an -r1 is needed to be honest, just submit a diff to the current ebuild :)
This will fix it... --- snort-2.8.5.1.ebuild 2009-12-16 14:46:41.887719845 -0500 +++ snort-2.8.5.1.ebuild.new 2009-12-16 14:55:05.700236755 -0500 @@ -82,6 +82,13 @@ unpack ${A} cd "${S}" + # Fix to prevent the docs Makefile from being used. + # Fixes #297190. + einfo "Applying documentation fix." + sed -i -e 's:src doc etc:src etc:g' \ + "${WORKDIR}/${P}/Makefile.am" || die "Doc fix Failed" + + # Fix to allow parallel building. # Thanks to Natanael Copa #291558 einfo "Applying parallel building fix."
I see this is still marked NEW. Is there anything else I need to do to close this?
Nevermind... a new version of snort was released today. I submitted a bug with an ebuild attached for the new version of snort. This fix is included in the new ebuild. Bug #299004
Comment #7 was added while I prepared the below text, but it may still be useful as general commentary. The fix ought to be in the Portage CVS tree before the bug is closed. If you have commit access and the proposed change is acceptable according to Gentoo standards[1], commit it and resolve the bug. If you are maintaining this via proxy, ask your proxy-maintainer to commit the fix on your behalf, then resolve the bug once the change has been committed. Resolving earlier might lead to someone reopening the bug because they obtained a tree without the fix. [1] Presumably meaning: does not cause a regression, fixes the reported problem, and there is no apparent "better" fix for the problem. Exact meanings may vary. I am not a Gentoo developer, so this definition could be inaccurate, but is probably pretty close.
Thx for the info. I'm a proxy-maintainer, but will keep this in mind for the future. (In reply to comment #8)
This is fixed in the current version of snort in portage (Snort-2.8.5.3)
