Created attachment 317766 [details] emerge --info The failure is early on in the process: >>> Source unpacked in /var/tmp/portage/net-analyzer/wireshark-1.8.0/work >>> Preparing source in /var/tmp/portage/net-analyzer/wireshark-1.8.0/work/wireshark-1.8.0 ... * Applying wireshark-1.8.0-underlinking.patch ... [ ok ] cp: cannot stat `//usr/share/libbtbb/wireshark/.': No such file or directory
09 Jul 2012; Rick Farina <zerochaos@gentoo.org> metadata.xml, wireshark-1.8.0.ebuild: add in support for third-party-plugins, starting with btbb How was that ever going to work?
files/wireshark-1.8-btbb.patch has landed in gentoo-x86/net-libs/libbtbb/files/ for some reason, not in the wireshark files directory. Why would you go through: cp -r "${EROOT}/usr/share/libbtbb/wireshark/." "${S}/" || die using a complete directory from the libbtbb ebuild and then apply the single patch from there? Please revert your commits and offer them for review to the netmon team.
(In reply to comment #0) > Created attachment 317766 [details] > emerge --info > > The failure is early on in the process: > > >>> Source unpacked in /var/tmp/portage/net-analyzer/wireshark-1.8.0/work > >>> Preparing source in /var/tmp/portage/net-analyzer/wireshark-1.8.0/work/wireshark-1.8.0 ... > * Applying wireshark-1.8.0-underlinking.patch ... [ > ok ] > cp: cannot stat `//usr/share/libbtbb/wireshark/.': No such file or directory By any chance, did you try to install with --nodeps? There are deps for a reason and this will NOT work without the required net-libs/libbtbb-0.8-r1 installed, that's why it is a dep...
Fixed by reverting to the working state. Thanks for reporting!
@zerochaos: Please file a new bug with your enhancement proposals.
Since you don't want to actually file a new bug report, here goes the reasoning for reverting the wireshark commit. 1) Wireshark has tons of security bugs, and getting the latest release stable in the tree should go quickly and painless. Adding third party plugins using patches means we may need to wait for these to be rewritten for the new release, or dropping the patches. 2) Even if applying third party patches were acceptable, installing a patch using the libbtbb ebuild and then applying it in the wireshark ebuild is silly - you might as well apply it directly in the wireshark ebuild by extracting the patch from the libbtbb SRC_URI. It doesn't just look silly - it becomes a huge maintenance problem when you need to upgrade libbtbb and tie wireshark to a specific libbtbb version/revision in order to fix/improve the patch. What if you bump wireshark and find the patch doesn't apply anymore? You drop the patch again and all the added logic in the ebuild that enables that? In light of the ease of applying the patch from SRC_URI, why bother doing that at all? 3) The cp -r wasn't needed at all if you had simply copied the file.
(In reply to comment #6) > 2) [...] installing a patch > using the libbtbb ebuild and then applying it in the wireshark ebuild is > silly - you might as well apply it directly in the wireshark ebuild by > extracting the patch from the libbtbb SRC_URI. [...] In general this idea also breaks the atomicity of a package's build. IE, the package should in and of itself contain all of the source files it needs in order to build itself. It can rely on other things that it will link to (ie libs) or programs it can run (the toolchain, pkg-config, etc), but it shouldn't change its source based on what's installed. Indeed, even patches which are only installed given certain conditions (use flags, has_version) are frowned upon, never mind patches that are coming from outside of the package as a whole. AFAIK, the EPATCH_USER stuff is (when supported) the only outside-of-package patching which is permitted on a package. To the overall idea, it would probably be best to follow the example of other third-party plugins: use a USE_EXPAND to enable the necessary bits for each third-party package, and provide the patches for each third-party plugin in a big separate distfile, already vetted and sure to apply cleanly to a given wireshark distfile. This would #1 - mean that the build source is atomic to itself and not changing based on the state of @world, and #2 - that the binpkg image of wireshark would only be dependent on the use flags set to it (instead of the random state of @world). Also, addressing rej's '1)' , security management and other compile-time maintenance of wireshark will be easier when it and all of its (potential) patches are together, rather than having to manage wireshark's security in tandem with who-knows-how-many-other-independent-packages. Otherwise, source code inspection would be virtually impossible.
