On 02/09/2010 12:29 AM, f...@kokkinizita.net wrote:
On Mon, Feb 08, 2010 at 03:47:47PM -0600, Aaron Griffin wrote:
When I attempt to install app-baz, which pulls in libfoo 2.0, how do
you expect to resolve all the conflicts that result from keeping
libfoo 1.0 on the system at the same time as libfoo 2.0? All sorts of
things are in conflict here. There's no way to automatically cover
these cases that I can see
There are no conflicts resulting form doing this.
Suppose I have a fresh install with:
(-> means a symlink)
libfoo.so -> libfoo.so.1.2.3
libfoo.so.1 -> libfoo.so.1.2.3
libfoo.so.1.2.3. // the actual library
and all apps have been linked to libfoo.so.1
When the library is updated as the result of
e.g. installing a new package (and meanwhile
the library version for the whole repo has
changed) there are two possible scenarios:
1. Bugfix, security update or small enhancement:
the library is fully compatible with the previous
one and has the same major version number. The
result is e.g.:
libfoo.so -> libfoo.so.1.3.5
libfoo.so.1 -> libfoo.so.1.3.5
libfoo.so.1.3.5. // the actual library
All apps use the new version.
2. A new major version of the library (very
probably incompatible). The result is:
libfoo.so -> libfoo.so.2.1.1
libfoo.so.1 -> libfoo.so.1.2.3
libfoo.so.1.2.3. // the actual library
libfoo.so.2 -> libfoo.so.2.1.1
libfoo.so.2.1.1. // the actual library
So pacman has installed libfoo.so.2.1.1, created
the symbolic link to it from libfoo.so.2, and
modified the symbolic link from libfoo.so to
point to the new version.
The result of this is that:
1. The newly installed package will use the
new library as it expects 'libfoo.so.2'.
2. The other applications will continue to use
the old version, as they expect 'libfoo.so.1'.
In other words they will still work. A smart
user will probably update them soon, but is
not forced to do this immediately.
3. Recompiling anything locally will use the
new version as during compilation you use
the name 'libfoo.so' without version number,
which, using the symbolic link, gets coded
into the binary as 'libfoo.so.2'.
*** There is no conflict. *** Pacman can forget
about and even delete the package that supplied
the old version. It just *should not remove the
old library itself*.
you are focusing only on .so which is different but this schema will
work only if the package is split in lib, -dev, whatever as now, the
headers will conflict since it have the same name on the same location.
--
Ionut
