Norm Jacobs wrote: > Raj Prakash wrote: >> >> This information is Copyright 2009 Sun Microsystems >> 1. Introduction >> 1.1. Project/Component Working Name: >> GCC4: The GNU Compiler Collection 4.X >> >> 4. Technical Description: >> 4.1. Details: >> Commands will be installed in /usr/bin with versioned suffixes, >> e.g. gcc-4.3.2. The runtime libraries will be installed >> /usr/lib with major, minor, and patch suffixes as appropriate >> along with a link for the major version, e.g >> libstdc++.so.6.0.10 and libstdc++.so.6 -> libstdc++.so.6.0.10. >> See section 4.5 Interfaces below for additional details. >> >> This case proposes to modify the previous release, >> LSARC/2008/776 GNU Developer Collection, as follows: >> >> 1) Localized message files will be moved from /usr/share/locale >> to /usr/lib/gcc/<machine>/<version>/share/locale. >> >> 2) Runtime libraries will be refactored from a single package >> into multiple packages, one package per library, to allow >> individual libraries to be upgraded in future releases. > Did I understand correctly that you are refactoring the packaging so > that you can potentially deliver different pieces of gcc from different > releases of gcc in the future?
This is actually to allow for the future possibility of the major version of one of the libraries changing. For example, GCC 4 provides libone.so.6 and libtwo.so.4 while GCC 5 provides on libone.so.7 and libtwo.so.4. If we made a single package containing all of the runtimes for each release as we do now, there would be a duplicate pathname, libtwo.so.4, between gccruntime4 and gccruntime5. Separating the runtime libraries into individual packages based on their major version numbers would avoid this problem. Thanks, George > > -Norm >
