Am 26.08.2014 um 13:22 schrieb Michael Stefaniuc:
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.
@Michael: I know that, we're also maintaining Fedora packages, and for those thats easy to solve - but basically all other distributions (intentionally) don't do this, because they don't want to end up with thousands of packages, and almost all dependencies are required anyway. When providing precompiled packages, the goal is that they work without further effort for the average use-case, but still allow more complicated setups with some manual effort.
For components that are required by a lot of applications splitting doesn't make sense, and all other dependencies are dynamically linked so far, and can easily be marked as optional dependency. For the user its very easy to enable additional features in Wine by just installing the optional dependencies, no manual rebuild required. I know that different distributions might have different opinions on that, but thats basically the way it works for a lot of them (for example all Archlinux and Debian builds, most likely also a lot more distributions). Wpcap is a bit special, because only few applications require it, and moreover it even requires the user to _manually adjust permissions_ on the wine-preloader executable. I would like the users to be able to do that, but without recompiling wine.
@Julliard: Basically every build tool chain complains when linking statically against a library, which is not marked as dependency. But its your decision of course, I'm pretty sure I'll find a solution, I was just hoping for a general way to solve this upstream. Thanks anway.
Regards, Sebastian
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.