[xmlsec] versioning and library naming policies

[John Belmonte]

First I'll summarize my response:  Aleksey (perhaps with input from the 
community) should decide one basic thing:

     Should xmlsec have library versioning so that multiple versions can exist 
within one OS installation or not?

Of course, there is going to be a tradeoff between complexity and flexibility, 
so the question should be seriously considered.  However, if the answer is 
"yes", I strongly recommend we follow the established techniques of other 
libraries such as libgimp (beginning with 1.3), libtk, etc.

Aleksey Sanin wrote:
> 0) Package name.
>  From now on the package name changes from "xmlsec" to "xmlsec-0.0",
> "xmlsec-0.1" and so on.

ok

> 1) Include files.
> The include files are move from "$(prefix)/include" to 
> "$(prefix)/include/xmlsec-0.0",
> "$(prefix)/include/xmlsec-0.1", ... folders.

ok

> 2) Library files.
> 2.1) Library files are moved from "$(prefix)/lib" to 
> "$(prefix)/lib/xmlsec-0.0",
> "$(prefix)/lib/xmlsec-0.1", ... folders.
...
> The static library names have *not* changed.

I don't agree with this.  There shouldn't be a directory for the library files 
because the version is included in the file names.  The static library name 
should include the version also.  Yes, this means that applications must choose 
which version they want to link against.

> 3) xmlsec-config script
> xmlsec-config script have updated to return new paths, etc. From now on there
> will be two scripts: xmlsec-config and xmlsec0-config (xmlsec1-config, ...)
> If you want to link against particular xmlsec version, use the "numbered"
> version.

I don't understand what the meaning of xmlsec0-config and xmlsec1-config is-- 
they should be xmlsec-0.0-config and xmlsec-0.1-config, etc.  (Remember that the 
soname number gets reset to 0 for each different -release.)  There should be no 
default "xmlsec-config".  Again, that means that applications much choose which 
version they want to link against.  That's what library versioning is about.

> 4) man pages
> Same as xmlsec-config script: two man pages "xmlsec.1" and "xmlsec0.1" 
> ("xmlsec1.1", ...).

I disagree, same as 3).

> Everything works just fine if we say that multiple xmlsec packages (xmlsec
> runtime) is allowed on the box but only *one* xmlsec-devel (xmlsec sdk). And
> I wonder if anybody thinks that we go with this.

Being able to develop for multiple versions is useful.  What if I have old 
library A that uses xmlsec-0.0, and new application B that uses xmlsec-3.0? 
What if both A and B are part of the same larger system?  How do I compile? 
Another situation: how do I test my application against the new xmlsec-0.1 
without distrupting my stable build environment that uses xmlsec-0.0?

Therefore I suggest to either stick with the current simple non-version system, 
or go with the complex flexible system.  Adding 90% of the complexity to get 
only 50% of the flexibility is not a good value.

Aleksey Sanin also wrote:
> Does not work:
>    1) after this you need to do " libxmlsec-$(RELEASE)_SOURCES=...."  :)

You are correct.  Painful, but it does work :-).

>    2) this breaks linking to libxmlsec.so -> libxmlsec-0.1.so.0.1.1 

There shouldn't be a libxmlsec.so, same argument as above.


Regards,
-John



-- 
http:// if   l .   /