[Moving to tech-toolchain.
 Summary: Update builds broken b/c of stale libssp* files in destdir]

On Sat, Jun 02, 2007 at 02:34:42 +0400, Valeriy E. Ushakov wrote:

> It certainly does run postinstall-fix-obsolete target, update build or
> not.
> 
> People forgetting to mark files as obsolete is a different issue :)

I've brought back static and lint ssp libs and marked them as
obsolete.

Now, the so's are a different matter.  The problem with .so's is that
there might be locally compiled apps (i.e. not in the base system)
that are linked against the "obsolete" .so's.  If those "obsolete"
.so's are removed, the apps get broken.

postinstall fix obsolete can automatically clean up lib dirs from old
minor versions (so we don't need to have an obsolete entry for each
minor version in the set lists), but it doesn't touch old major
versions.  It has code to do so, but it's not enabled (there's even no
command line option to enable it).

For major version bumps we could 1) remove list entries instead of
marking them obsolete, and 2) run postinstall-fix-obsolete target with
AllLibs enabled.  We only run postinstall-fix-obsolete for builds that
are not in-place, so it should be safe, it will clean the destdir (b/c
of #2), and it will not touch obsolete major versions in an installed
system (b/c of #1).

That still doesn't address the issue of removing a library though
(there's no newer major version to trigger the deletion of the library
in the destdir by postinstall running with AllLibs enabled).


Thoughts?

SY, Uwe
-- 
uwe@stderr.spb.ru                       |       Zu Grunde kommen
http://snark.ptc.spbu.ru/~uwe/          |       Ist zu Grunde gehen