Hi Scott, Scott Cantor <[EMAIL PROTECTED]> writes:
> But as a practical matter, it's a problem for packaging systems if they > can't depend on "owning" the files they think they own. I come from the Debian world so what I know about packaging may not apply elsewhere. I don't see how the current way of doing things can cause problems to packagers. On Debian you can install Xerces-C++ 2.7.x and 2.8.y side by side. However, if there is a new bug-fix release for say 2.8.y (or even a new package revision) then it upgrades your existing 2.8.y installation instead of installing a new version in addition to the existing 2.8.y. This also makes a lot of sense to me: why would you want to keep the old 2.8.y if you have a binary-compatible newer (and presumably better) version. Perhaps for packages which don't have a well defined versioning system (e.g., 2.3.0 -> 2.4.0 transition can be both binary compatible or not), -version-info makes more sense. Even if we assume that we go the -version-info way, then there are other things that can conflict. What about example binaries, they don't have any version embedded into them? Also some configurations may require extra files (e.g., message catalogs) for which the versioning system provided by the runtime linker for libraries is not available. Boris -- Boris Kolpackov, Code Synthesis Tools Open source XML data binding for C++: http://codesynthesis.com/products/xsd Mobile/embedded validating XML parsing: http://codesynthesis.com/products/xsde --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
