Onward branch

Gilles Espinasse g.esp at free.fr
Wed Sep 17 08:57:12 PDT 2008


Selon Jan Dvorak <jan.dvorak at sitronicsts.com>:

> On Wednesday 17 September 2008 15:57:40 Chris Buxton wrote:
> > add a version number and you have the
> > ability to keep an old version around when upgrading.
>
> Possibly, yes.
>
> The main problem here lies with package upgrades themselves. How reliable
> is to have newer version of this library while this app was linked
> against the older version? They may or may not be binary compatible. The
> best would be to recompile against newer version, but... rebuild whole
> system after glibc? Or just *rebuild* (not upgrade) direct dependencies?
>
It depend of the lib, some work, other not, some complain when the lib version
differ.

That's why it is convenient to check with a control sum (md5 or sha1) if the
resulting program is the same or different with old and new library.
This is where including compilation date inside the binary is bad as you can't
check anything without removing the timestamp.

md5 sometime is different only because the binary include against wich version
of the dependencies it has been compiled.

It is easy to check md5 when compiler is unchanged, but if compiler is
maintained, the md5 of the compiled program may not be vary with compiler
version.

> You can rely on library names and patch all libraries to include version
> numbers after .so the way libtool does, but that would require some
> effort. My tip would be... use debian sources, read debian/rules to get
> correct build options and tweaks plus apply non-debian-only patches. Or
> Fedora if you prefer reading .spec files.
>
Once there is no more a compilation timestamp on the program, you don't need to
create artificial dependencies on libraries in the case program is the same with
both libraries versions.

Gilles



More information about the hlfs-dev mailing list