how to fix WARNING: QA Issue: libpam: installed in the base_prefix, requires a shared library under exec_prefix

how to fix WARNING: QA Issue: libpam: installed in the base_prefix, requires a shared library under exec_prefix

[Yao Zhao]

Hi all,

Any suggestion to fix these kinds of QA warnings?

libpam is referencing /usr/lib/libcrack from /lib/security.

I tried to fix cracklib to install to /lib but cracklib is using other 
libraries from /usr/lib, I am afraid that I am touching a chain, so any 
good ideas?

thanks,
yao

Re: how to fix WARNING: QA Issue: libpam: installed in the base_prefix, requires a shared library under exec_prefix

[Mark Hatle]

On 8/3/12 11:44 AM, Yao Zhao wrote:
> Hi all,
>
> Any suggestion to fix these kinds of QA warnings?
>
> libpam is referencing /usr/lib/libcrack from /lib/security.
>
> I tried to fix cracklib to install to /lib but cracklib is using other
> libraries from /usr/lib, I am afraid that I am touching a chain, so any
> good ideas?

Historically I'm used to cracklib being in /lib... but I also don't remember a 
huge chain of additional libraries.

It may be worth identifying the chain and seeing if we can break it, or at least 
reduce it in some fairly easy way.

--Mark

> thanks,
> yao
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>

Re: how to fix WARNING: QA Issue: libpam: installed in the base_prefix, requires a shared library under exec_prefix

[Yao Zhao]

On 12-08-03 01:45 PM, Mark Hatle wrote:
> On 8/3/12 11:44 AM, Yao Zhao wrote:
>> Hi all,
>>
>> Any suggestion to fix these kinds of QA warnings?
>>
>> libpam is referencing /usr/lib/libcrack from /lib/security.
>>
>> I tried to fix cracklib to install to /lib but cracklib is using other
>> libraries from /usr/lib, I am afraid that I am touching a chain, so any
>> good ideas?
>
> Historically I'm used to cracklib being in /lib... but I also don't 
> remember a huge chain of additional libraries.
>
libcrack is depending on libz and libz is in usr/lib too.
Seems libz didn't depend another.

What exactly reason that this is a serious problem? Is this a standard?
It is quite possible that a lib library depending on usr/lib then .....
Do we have a one-shot cure?

yao
> It may be worth identifying the chain and seeing if we can break it, 
> or at least reduce it in some fairly easy way.
>
> --Mark
>
>> thanks,
>> yao
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: how to fix WARNING: QA Issue: libpam: installed in the base_prefix, requires a shared library under exec_prefix

[Mark Hatle]

On 8/3/12 1:07 PM, Yao Zhao wrote:
> On 12-08-03 01:45 PM, Mark Hatle wrote:
>> On 8/3/12 11:44 AM, Yao Zhao wrote:
>>> Hi all,
>>>
>>> Any suggestion to fix these kinds of QA warnings?
>>>
>>> libpam is referencing /usr/lib/libcrack from /lib/security.
>>>
>>> I tried to fix cracklib to install to /lib but cracklib is using other
>>> libraries from /usr/lib, I am afraid that I am touching a chain, so any
>>> good ideas?
>>
>> Historically I'm used to cracklib being in /lib... but I also don't
>> remember a huge chain of additional libraries.
>>
> libcrack is depending on libz and libz is in usr/lib too.
> Seems libz didn't depend another.
>
> What exactly reason that this is a serious problem? Is this a standard?
> It is quite possible that a lib library depending on usr/lib then .....
> Do we have a one-shot cure?

The QA message is because the / (non-/usr) was originally designed to be the 
minimal boot environment, and then /usr would be added to provide the full 
system capabilities.  There are some advantages to this behavior for embedded 
systems, as it can allow for smaller footprint systems to be the boot environment.

With modern components like udev, systemd, and such, sometimes it's difficult, 
if not nearly impossible to have this split though, as many of the components 
require libraries and/or binaries that normally reside in /usr.   Generally we 
have the choice to either move the libraries or binaries, or break the 
dependency on those items (by changing the configuration, statically linking, or 
changing the behavior so the library/binary is no longer needed.)

I suspect libz is needed because the cracklib dictionary is compressed. 
Dependending on usage, it may make sense to statically link libz into libcrack, 
and move libcrack to /lib.

--Mark

> yao
>> It may be worth identifying the chain and seeing if we can break it,
>> or at least reduce it in some fairly easy way.
>>
>> --Mark
>>
>>> thanks,
>>> yao
>>>
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>>
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>

Re: how to fix WARNING: QA Issue: libpam: installed in the base_prefix, requires a shared library under exec_prefix

[Yao Zhao]

On 12-08-03 02:22 PM, Mark Hatle wrote:
> On 8/3/12 1:07 PM, Yao Zhao wrote:
>> On 12-08-03 01:45 PM, Mark Hatle wrote:
>>> On 8/3/12 11:44 AM, Yao Zhao wrote:
>>>> Hi all,
>>>>
>>>> Any suggestion to fix these kinds of QA warnings?
>>>>
>>>> libpam is referencing /usr/lib/libcrack from /lib/security.
>>>>
>>>> I tried to fix cracklib to install to /lib but cracklib is using other
>>>> libraries from /usr/lib, I am afraid that I am touching a chain, so 
>>>> any
>>>> good ideas?
>>>
>>> Historically I'm used to cracklib being in /lib... but I also don't
>>> remember a huge chain of additional libraries.
>>>
>> libcrack is depending on libz and libz is in usr/lib too.
>> Seems libz didn't depend another.
>>
>> What exactly reason that this is a serious problem? Is this a standard?
>> It is quite possible that a lib library depending on usr/lib then .....
>> Do we have a one-shot cure?
>
> The QA message is because the / (non-/usr) was originally designed to 
> be the minimal boot environment, and then /usr would be added to 
> provide the full system capabilities.  There are some advantages to 
> this behavior for embedded systems, as it can allow for smaller 
> footprint systems to be the boot environment.
>
> With modern components like udev, systemd, and such, sometimes it's 
> difficult, if not nearly impossible to have this split though, as many 
> of the components require libraries and/or binaries that normally 
> reside in /usr.   Generally we have the choice to either move the 
> libraries or binaries, or break the dependency on those items (by 
> changing the configuration, statically linking, or changing the 
> behavior so the library/binary is no longer needed.)
>
> I suspect libz is needed because the cracklib dictionary is 
> compressed. Dependending on usage, it may make sense to statically 
> link libz into libcrack, and move libcrack to /lib.
>
thanks Mark!
I have modified zlib and cracklib both to install to /lib. In case there 
are other packages installed to /lib but need libz too.
patch soon.

yao
> --Mark
>
>> yao
>>> It may be worth identifying the chain and seeing if we can break it,
>>> or at least reduce it in some fairly easy way.
>>>
>>> --Mark
>>>
>>>> thanks,
>>>> yao
>>>>
>>>> _______________________________________________
>>>> Openembedded-core mailing list
>>>> Openembedded-core@lists.openembedded.org
>>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>>>
>>>
>>>
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core