Bug 760167

Forgot to mention that one could argue that it's a bug in JDK that it looks for the unversioned symlink.  However, it does that on purpose and it's the documented behavior, so I think it's best to "fix" it this way instead of patching OpenJDK to behave some other than the documented way.

Why do you think the JVM is right?
Why does it use the .so instead of .so.1 "on purpose"?

I do not think nor did I say the JVM is right.  I did not code or design that stuff so I cannot answer why it is done that way, but it is clearly on purpose because they have even documented for years that it uses the unversioned *.so.  

Just moving the symlink to pcsc-lite-libs is a harmless way to work around this for all JVMs that ship the SunPCSC provider.

The other option of tweaking the JVM would mean changes to both java-1.6.0-openjdk and java-1.7.0-openjdk in Fedora and those changes would make their behavior deviate from how they are documented to behave.  And it still would not help users of other JVMs.

The third option of leaving things as they are now is the worst of them all and leaves things broken out of the box for everyone.  Unless of course people install pcsc-lite-devel for this purpose, which is just confusing and wrong.

I do not plan to release a libpcsclite.so.2 in the foreseeable future. So adding the .so in the -libs package may not be problematic for now.

By doing this you will make it impossible to install at the same two libpcsclite libraries with two different ABI, like it was the case with libpcsclite.so.0 and libpcsclite.so.1.

I think Sun/Oracle do not know what they are doing when they use the .so instead of .so.1 name. It will break at the first ABI change.

(In reply to comment #4)
> By doing this you will make it impossible to install at the same two
> libpcsclite libraries with two different ABI, like it was the case with
> libpcsclite.so.0 and libpcsclite.so.1.

No, that wouldn't be impossible.  The unversioned symlink would just point to the newer one of those (~ i.e. would probably be in the package providing the newer lib).  Similar considerations would apply anyway with the current packaging setup, it'd just be for -devel, not -libs.  Anyway I'd be quite surprised if Fedora would ship two versions of libpcsclite except for a very short transitional period in the devel branch.

> I think Sun/Oracle do not know what they are doing when they use the .so
> instead of .so.1 name. It will break at the first ABI change.

I find their approach strange too, but for now it is easily worked around by the patch in this bug.  If/when ABI breakage occurs so that this stuff no longer works, _then_ it needs to be fixed one way or another in their code in any case, or it will break.  But IMO that's not a good reason to keep things broken *now*, nor to try predicting the future exactly what changes would need to be made in the JDK.

I think it's up to pcsc-lite upstream to tell people how to use the library. The upstream is saying to dlopen libpcsclite.so.1 instead of libpcsclite.so, which means that the fix should go in the JVM package.

Plus, for consistency with other distros, I'd keep the libpcsclite.so symlink in -devel. Otherwise we might end up in a situation where people writing client apps end up relying on the .so symlink, and the app would break on another distro.

With open source, we have the luxury to fix things at the right place, instead of doing workarounds. Could you please try to get this sorted out in openjdk packages instead?

P.S. Updated pcsc-lite to 1.8.2 in rawhide (F17).