Hi Wolfgang,
I found externals to be not very practical. The reason for this is, that
I want to be able to freeze the current state of opensc as a tag so I
can later have a look what was in that version. With externals, only the
reference is copied to the tag, but the reference can change. and
tagging the referenced repository too or something like that ends up
being a major pain.
So I think managing a few copies of pkcs11.h isn't such a big deal.
I can write a cron job that will get the trunk copy of every know
source and send me an email when something is not in sync, so we will
find out quite fast. A second script could download from the master
repository and distribute the file to all that have copies.
Also if we use an remote repository (i.e. on a different server) as
externals - e.g. something by the gnupg people - and their server is
unreachable, then you can't get a full checkout.
In summary I can say: I prefer central management of local copies over
local management of central copies. Whether it is a header file or
something completely different, the same patterns are found in many
places. My experience is that managing local copies is much easier -
but it is only possible if you control those. In the case of our
svn repositories that is the case.
Also currently I count only two copies - opensc and libp11.
gtkcard and pam_pkcs11 contain the old/official rsa pkcs#11 header file
as far as I know.
$ cat bin/check_phcs11_h
#!/bin/bash
set -e
cd ~/pkcs11_check
svn export svn://cvs.gnupg.org/scute/trunk/src/ scute
mv scute/pkcs11.h pkcs11_h_scute
rm -rf scute
wget http://www.opensc-project.org/svn/opensc/trunk/src/pkcs11/pkcs11.h \
-O pkcs11_h_opensc
diff -ud pkcs11_h_scute pkcs11_h_opensc || true
wget http://www.opensc-project.org/svn/libp11/trunk/src/pkcs11.h \
-O pkcs11_h_libp11
diff -ud pkcs11_h_scute pkcs11_h_libp11 || true
rm pkcs11_h_*
what do you think?
Regards, Andreas
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
