Bug#663541: error: alternative path /usr/share/java/swt-gtk-3.7.jar doesn't exist
niels at thykier.net
Mon Apr 2 16:57:43 UTC 2012
On 2012-04-02 03:26, Witold Baryluk wrote:
> On 04-02 02:45, root wrote:
>> Package: libswt-gtk-3-java
>> Version: 3.7.2-1
>> Followup-For: Bug #663541
>> Hi, I have same problem.
>> Similary to reporter I have /usr/share symlinked to another filesystem.
>> It is unusual, but why postinst script assumes anything about filesystem?
>> I think bug is still valid, and not yet resolved.
> I read FHS 2.3, and it clearly says that /usr/share can be directory or symlink.
> Also it make sense, to use symlink sometimes as it is sharable data by
> various architectures.
> I currently workaround this problem by using 'mount /some/path/share /usr/share -o bind',
> and modified /etc/fstab accordingly. Symlink would be much simple way.
> There is multiple packages in my systems with such problem:
> root at tytus:~# ls -l /usr/share/java/ | grep '\.\.'
> first 3 in this lists, and one more later, works because, they or only using ../, other was broken because they was using ../../,
> and landed not in /usr/, but in /some/path/, which doesn't contain lib/ subdirectory.
> SO I could workaround it by hack, and create symlink /some/path/lib to /usr/lib. :)
> In fact I tested it, and this also works.
> Is there any Debian policy, preventing me having /usr/share as symlink?
The Debian Policy Manual (§10.5) requires us to use relative links
within /usr, so I guess in some sense it prevents you from having
/usr/share as a symlink if that breaks relative symlinks in Debian packages.
It is possible that Debian Policy needs to be amended here. In that
case, please file a separate bug against the debian-policy package.
> Cannot swt-gtk-3.7.jar be not a symlink, but actual file? Most jar's are
> arch-independent (as they are bytecode), and can safely reside in
> /usr/share/java/. I guess, there are few exceptions (like jars which
> have also some native code), and need to reside in /usr/lib/java/, and
> symlinking make it quite simple to achive. Is this the case in
SWT is an exception to the rule of "architecture independent byte code".
> I checked it and it only contains .class files. This package is
> arch-specific, and each Debian arch have its own verion, but package
> size is almost identical everywhere, makeing me wonder what is actually
> this difference. Clearly a real interfacing to C GTK+ code, is done in
> .so files from libswt-gtk-3-jni package, so why we have arch-specific
> -java one?
Admittedly, I am not sure why we have so many libswt-gtk-* packages, I
guess it is an artifact from when we inherited the packages from the
However, we do need the -java package to be architecture specific last I
checked (admittedly that was 3.5 or so). Upstream uses different data
types on 32 bit machines (int) vs 64 bit machines (long) for pointers.
This results in different method signatures in the JAR file and
therefore also different byte code.
Admittedly, I am not too pleased with the idea of symlink from
/usr/share/java to /usr/lib/java. Unfortunately we have reverse
dependencies relying on this symlink, so it is a non-trivial transition.
More information about the pkg-java-maintainers