On 12/12/06, Steve Langasek <[EMAIL PROTECTED]> wrote: ...
I don't see any conflicts between the -java packages, only the -jni packages. I guess the -jni packages do need to conflict with each other then, if they have file conflicts.
Thank you for bringing to my attention that only the -jni packages conflict. The fundamental reason the two packages conflict is that they provide exactly the same libraries. So, to close bug #376672 (libswt-gtk-3.1-java conflicts libswt3.1-gtk-java) it occurred to me that libswt-gtk-3.1-java could depend on libswt-gtk-3.2-jni | libswt3.2-gtk-jni. The catch is that both JNI libraries are somewhat misnamed, because version 3.2-1 of both packages provided the soname libswt-gtk-3232.so, whereas version 3.2.1-1 of the packages provide the soname libswt-gtk-3235.so. If 3.2.2-1 is also released under the package name libswt3.2-gtk-jni (likely), it will not be suitable to provide the needed dependency (namely, libswt-gtk-3235.so). So, I need to depend as an alternative on libswt3.2-gtk-jni (>> 3.2.1 && << 3.2.2). How do I accomplish this? So far I have... Package: libswt-gtk-3.2-java Depends: libswt-gtk-3.2-jni (= ${binary:Version}) | libswt3.2-gtk-jni (>> 3.2.1) One solution would be for both libswt-gtk-3.2-jni and libswt3.2-gtk-jni to provide a pseudo-package libswt-gtk-3235-jni and depend on that. The only downside is that both SWT packages have to be modified to support this mechanism. Cheers, Shaun -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]