On 08/26/2014 12:47 PM, Sebastian Lackner wrote:
Linking it dynamically has a great advantage for distributions and package maintainers providing precompiled wine builds. I would also like to provide my wine builds with wpcap support (some users might want to use it) - but when I do that a fixed dependency is required. This is especially confusing when wine is only used as a dependency, like in case of pipelight, where users are already wondering why we now depend on libpcap (those are wine builds where it was already enabled): https://answers.launchpad.net/pipelight/+question/253591
I guess other package maintainers might probably think the same, but most haven't updated to 1.7.25 yet, and are not aware of this problem. Just converting the static dependency to a dynamic dependency would be the easiest approach to solve this - the alternative would be to split wine into (more) packages, and avoid the libpcap dependency on the main one... or just leave this feature exclusively for source-based distros where users have fine-grained control about which features they want. :/
Fedora has subpackages for all those components requiring extra dependencies. In this case I guess they will go for a wine-pcap rpm. Installing the wine package will pull everything in. But the people that do care about the dependencies they have the granularity required.
bye michael
Am 26.08.2014 um 11:55 schrieb Alexandre Julliard:
André Hentschel nerv@dawncrow.de writes:
This is intended for packagers, without this patch libpcap easily becomes a fixed dependency of wine. Something we don't want i guess.
It's only used for wpcap, which can't work without it anyway, so I don't see any need to make it dynamic.