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 . /
_______________________________________________ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
