diff -r afeba86077f1 -r b696a44762ea opensc/README
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/opensc/README	Thu Mar 15 21:52:52 2012 +0100
@@ -0,0 +1,37 @@
+NOTE
+
+It seems there are problems with opensc(5) and pcscd(8) coexistence.
+
+It has been observed that pcscd(8) performs correctly in the absence
+of /usr/lib/opensc-pkcs11.so. Namely, pcscd(8) does not run until a
+end user accesses the smart card harware using a client application.
+Once this happens, pcscd(8) starts with user and group permissions
+of the end user and the client application procedes normally.
+
+Should /usr/lib/opensc-pkcs11.so be present, pcscd(8) starts at
+system boot with root privileges. Once a end user accesses the smart
+card hardware, a second instance of pcscd(8) is launched, the script
+/etc/init.d/pcscd is executed with the end user's user and group
+permissions. The script causes deletion of /var/run/pcscd where
+important connection information is stored by the first pcscd(8)
+instance running with root privileges. It may be this deletion
+which causes all client applications to fail to access the smart
+card hardware.
+
+The workaround is to manually edit the script /etc/init.d/pcscd
+so that /var/run/pcscd is not removed, but this appears to be
+a short lived hack. Adequate testing has not proven this approach
+to be correct.
+
+  # FIXME: Fat bug, don't overwrite important
+  # FIXME: preexisting pcscd(8) connection data!
+  [ -e $IPCDIR/$NAME.comm ] && exit 0
+
+SCDAEMON BLOCKED
+
+Problems exist when using applications calling scdaemon(8) which
+locks access to the card reader. No solution exists, rather a
+workaround is to forcefully kill the scdaemon(8) server. This
+is a problem for those users of gpg(1) because of its indirect
+usage of scdaemon(8) and inability to call opensc(5) for any
+PKCS functions.