[xmlsec] versioning and library naming policies
jvb at prairienet.org
Tue Apr 1 19:23:20 PST 2003
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.
> 1) Include files.
> The include files are move from "$(prefix)/include" to
> "$(prefix)/include/xmlsec-0.1", ... folders.
> 2) Library files.
> 2.1) Library files are moved from "$(prefix)/lib" to
> "$(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"
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.
http:// if l . /
More information about the xmlsec