On Tue, Aug 26, 2014 at 4:36 AM, Alexandre Julliard julliard@winehq.org wrote:
Apart from making the code more complicated, the end result is the same, either way the dependency is required for the library to work, so I don't see why it would have to be treated differently when packaging. If the packaging tools insist on making it a requirement just because they see a dll linked to it, I'd suggest fixing the tools.
So, just to be clear here about the tradeoffs of the two solutions "fix the packaging tooling" or "make it dynamic in wine":
On Debian/Ubuntu, libpcap0.8-dev will need to be added to package build dependencies or a user will never be able to turn this feature on. This will cause Wine to statically link a dll, and for debhelper to then detect that static link, figure out it comes from the libpcap0.8 package, and add that dependency to the {$shlibs:Depends} substitution variable. This requires modifying the package rules file to override dh_shlibdeps to either 1) exclude calculating the particular DLL in question, or 2) manually remove libpcap0.8 afterwards.
Both those are fairly straightforward in deb-land. But, so is applying Andre's patch to a distro package. I don't know about tooling for other distros.