Please let us know your motivation for these changes.
Just for comparison to the RPM's, in Debian I have these packages:
libxmlsec1 - core shared library
libxmlsec1-<crypto> - individual crypto engine shared libraries
libxmlsec1-dev - headers, static libraries, and pkg-config
files for core and all crypto engines;
library documentation; xmlsec1-config
xmlsec1 - command line tool using default engineAs far as licensing, the important requirement is that application binaries and shared libraries only need depend on the crypto engine library that is suitable. That is why I broke out the crypto shared libraries into individual packages. There is no reason to do this for development files-- that would only increase the package maintenance burden.
As for the xmlsec1 tool, I think it's unfortunate that we need to expose the crypto engine differences to the poor command-line user. (I'm assuming that each flavor is going to end up with slightly different options or capabilities.) It's a bad sign that this needs to be done for xmlsec's model application. I wish the xmlsec library would hide the crypto engine differences and provide a uniform API-- but maybe that is a job for a wrapping library. It would be nice if the calling application could discover crypto engine capabilities at run-time. It would also be nice if the xmlsec library had neutral data structures and file formats for keys and such, so that the burden of dealing with various data formats would be shifted from the application writer to the crypto-engine writer.
I've never actually used the xmlsec API so I'm just guessing :-).
Regards, -John
-- http:// if l .o /
_______________________________________________ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
