On Sun, May 12, 2013 at 09:16:19PM +0100, Roger Leigh wrote: > Package: libc6 > Version: 2.17-1 > Severity: serious > Justification: ABI breakage > > __secure_getenv is being used by util-linux in libblkid.a. > Any program linked against libblkid.a will have a dependency > upon this symbol. This includes e2fsprogs, which currently > FTBFSes. There may be additional users; this is just the > one I'm aware of.
This was an internal function, that should not have been used. Given it has been used anyway, it has been decided to provide the secure_getenv function instead. > The new glibc has secure_getenv to replace __secure_getenv > but the old symbol is not retained. This is not true. __secure_getenv is still available and will be available forever (well as long as the soname doesn't change), it's just not possible to link against it: 856: 0000000000039a90 27 FUNC WEAK DEFAULT 12 __secure_getenv@GLIBC_2.2.5 1715: 0000000000039a90 27 FUNC WEAK DEFAULT 12 secure_getenv@@GLIBC_2.17 In short it's an API breakage, but not an ABI breakage. > I've NMUed util-linux to force it to be rebuilt. This > should fix the immediate issues. But the wider question is > how widespread was usage of this symbol, and do we need to > rebuild everything or could the symbol be restored for > backward compatibility? We should rebuild packages using it, but they are still functional until they are rebuilt. With all these explanations given, I think this bug can be closed, or at least the severity decrease, as the "Justification: ABI breakage" is not correct. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
