[xmlsec] build system changes

[John Belmonte]

Hi Aleksey,

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 engine

As 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  /