[arch-general] A suggestion for the devs regarding rebuilds

[Aaron Griffin]

On Mon, Feb 8, 2010 at 4:29 PM,  <fons at 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*.
>
> The system with major/minor version numbers and
> the symbolic links is actually designed to be
> used like this, and to permit different versions
> to co-exist on a system.

A package is not a single .so file, unless that is your proposal - to
split all .so files into their own packages.

Here is a list of files that would conflict if this was done with libpng:
libpng /usr/bin/libpng-config
libpng /usr/bin/libpng12-config
libpng /usr/bin/png2pnm
libpng /usr/bin/pnm2png
libpng /usr/include/libpng12/png.h
libpng /usr/include/libpng12/pngconf.h
libpng /usr/include/png.h
libpng /usr/include/pngconf.h
libpng /usr/lib/pkgconfig/libpng.pc
libpng /usr/lib/pkgconfig/libpng12.pc
libpng /usr/share/licenses/libpng/LICENSE
libpng /usr/share/man/man3/libpng.3.gz
libpng /usr/share/man/man3/libpngpf.3.gz
libpng /usr/share/man/man5/png.5.gz