Bug#593966: libc6: system-breaking (init OOPS) incompatibility with old prelink versions

[Andreas Mohr <andi@lisas.de>]

Package: libc6
Version: 2.11.2-2
Severity: critical
Justification: breaks the whole system (repeatedly, in a timebomb manner)

Hi,

beginning of August my intention was to upgrade a system (AMD64 i386
stable; libc6-i686 installed additionally) to KDE 4.4.x.
I chose to do this by temporarily switching to testing repository.
All went more or less fine, except for suddenly ending up with all
shell binaries segfaulting. A reboot resulted in /sbin/init dying with
a nice kernel OOPS. Full stop.

Found #586241 (somewhat related issue), which recommended dpkg-deb:ing
over the libc6 / libc6-i686 libraries to restore the system. Worked.
Hurray.

Ultimately, I managed to figure out that the problem is caused by an old
prelink version which doesn't seem to get along at all with new(er?) libc6
version. See also the initial warning report,
"prelink-2007* and libc6-2.11* don't mix.": http://lists.debian.org/debian-user/2010/06/msg02063.html

But, right after the upgrade, I hadn't realized the prelink issue
yet.

Note that, rather worse, prelink is cron-registered (cron.daily),
providing a nice time bomb by rendering a system fully unusable again the next day.
IOW, you copy over pristine libc6 libs, everything boots fine again,
you think it's all fixed ("must have been some stupid libc6 update issue"),
and one day later it's all broken again right when one is unavailable
to get this fixed (yup, you're staring at the person that this happened to).

The issue occurred with the old prelink 0.0.20090311-1 package,
updating to 0.0.20090925-1 fixed everything, no more prelink breakage.

Contrary to the conclusion in the rather helpful warning given by Boyd Stephen Smith Jr.
above (well, rather helpful if I actually had managed to find it in advance...),
I believe that something rather easy can and should actually be done about it,
to prevent other people from falling into the same very irritating trap:
provide a
Conflicts: prelink (<= 0.0.20090311-1)
package line or some such, which should hopefully be the proper means to
get this avoided.
I'm not sure of more precise version values to be provided here,
though, I only know of 0.0.20090311-1 behaviour.

libc6 specifics:
2010-07-31 19:11:57 upgrade libc6 2.9-25 2.11.2-2

Fallout of this issue really was not nice at all for me personally
(dead semi-production box for > 2 weeks, due to the cron timebomb complication),
thus myself I'd definitely want to see a protection applied,
despite being a __severe__ problem for a branch-hopping minority(?) only.

Thanks,

Andreas Mohr