[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#728529: [DSE-Dev] Bug#728529: libselinux1: causes ld.so error in smartctl/smartd



On 11.11.2013 09:34, Laurent Bigonville wrote:
> Le Mon, 11 Nov 2013 09:26:38 +0100,
> Sven Hartge <sven@svenhartge.de> a écrit :
> 
>> On 11.11.2013 09:22, Laurent Bigonville wrote:
>>> Le Mon, 11 Nov 2013 09:13:46 +0100, Sven Hartge
>>> <sven@svenhartge.de> a écrit :
>>
>>>> I see you reverted the fix you made and reassigned the bug to
>>>> eglibc6 with the commend "affected software needs to be
>>>> recompiled".
>>
>>>> I don't know if I like this "solution". What, if I am not able to
>>>> recompile an affected program?
>>
>>> A binNMU for smartmontools has just been schedule.
>>>
>>> The new rebuilt version (6.2+svn3841-1+b1) of smartmontools should
>>> arrive soon on the archive.
>>
>> All fine and dandy, but what if I have a software showing the same
>> problem, where I am not able to recompile, because I don't have any
>> source code for said software? (This is a hypotethical case.)
> 
> Calling ldd /usr/sbin/smartctl was also triggering the same assertion.
> 
> I tired to run ldd on all the executables that are depending against
> libselinux and only the executables from the smartmontools package were
> showing this issue, so the other packages in the archive /should/ be
> safe.

Everything from the package pools of Debian may be safe, yes.

But there are other programs from third party vendors, which may show
the same problem, which cannot be rebuild, because they are proprietary
software. What about them?

The way I see it is that libselinux1 and/or libc6 changed in an
binary-incompatible way and should be fixed in a way which does not
require a rebuild of eventually affected software.

Grüße,
Sven


Reply to: