George Vasick wrote:
> 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.
>
So what happens when GCC5 libtwo.so.4 differ GCC4 libtwo.so.4 due to bug
fix or worse? It may be that they never differ or never make
incompatible change without bumping the version. I just want to know
that it's not going to be a problem.
-Norm
