[lfs-dev] libcap vs libcap-ng

Bruce Dubbs bruce.dubbs at gmail.com
Fri Oct 24 16:14:20 PDT 2014


Armin K. wrote:
> On 24.10.2014 22:23, Bruce Dubbs wrote:
>> I notice that util-linux searches for libcap-ng (last release 0.7.4, 30
>> April 2014) in order to build setpriv.
>>
>> I've never used setpriv:
>>
>> "Sets or queries various Linux privilege settings that are inherited
>> across execve(2)."
>>
>> I don't know how useful that is, but we should probably build it if we
>> can.
>>
>> Does anyone know if libcap-ng is a drop-in replacement for libcap?
>>
>
> I don't think so. It provides a different library (libcap-ng.so) while
> other packages explicitly look for libcap.so. I build it for util-linux
> and gnome-keyring packages.

OK.  I'll ignore that in the book proper, but I suppose I ought to add 
it to the optional dependencies in Appendix C.

>> ------
>>
>> In a related matter, util-linux's configure does the right thing with
>>
>> ./configure ADJTIME_PATH=/var/lib/hwclock/adjtime \
>>              --docdir=/usr/share/doc/util-linux-2.25.2
>>
>> but it gives some warnings.  I can avoid the warnings with:
>>
>> /configure \
>>    --without-systemd \
>>    --without-systemdsystemunitdir \
>>    --without-python \
>>    --disable-chfn-chsh \
>>    --disable-login \
>>    --disable-su \
>>    --disable-setpriv \
>>    --disable-runuser \
>>    --disable-pylibmount
>>
>> Is that worthwhile?
>>
>
> I don't think it matters much, after all they are just warnings about
> optional packages not found. But, it may be useful to include some of
> these so some programs provided by other packages are not overriden by
> this one when upgrading the package and the optional dep is present for
> certain feature. 4th, 5th and 6th line come to my mind as they would
> overwrite utils provided by shadow if PAM is present when you rebuild
> (upgrade) util-linux.

That's a good point.  I'll change to that so that a rebuild gives 
consistent results and the user can change the options as desired.

   -- Bruce


More information about the lfs-dev mailing list