Le 03/01/2020 à 18:42, Joel Bion via lfs-dev a écrit :
> On 2020-01-03 07:40, Bruce Dubbs via lfs-dev wrote:
>> On 1/3/20 3:48 AM, Pierre Labastie via lfs-dev wrote:
>>> Le 02/01/2020 à 23:53, Bruce Dubbs via lfs-dev a écrit :
>>>> On 1/2/20 3:26 PM, Pierre Labastie via lfs-dev wrote:
>>>>> Second, use prefix=/usr for Make install, then move the shared library to
>>>>> /lib. But actually, if we do not pass prefix, the shared library is
>>>>> directly
>>>>> installed in /lib (note, we do need to pass lib=lib, but now
>>>>> RAISE_SETFCAP=no
>>>>> is the default). The only difference is that some binaries are installed
>>>>> in
>>>>> /usr/sbin if we pass prefix=/usr and they are installed in /sbin if not.
>>>>> Not a
>>>>> big deal, we do not use them anyway...
>>>>>
>>>>> I'll make a test build with the sed above and just "make lib=lib install"
>>>>> (without touching the library), and change the book if everything is OK.
>>>>
>>>> OK, thanks.
>>>
>
> I'd like to offer an opinion as to why things should stay as they are in the
> making of libcap.
>
> It's this:
>
> 1) Mechanisms with guaranteed results are more robust than depending on
> current defaults, that a package could change at any time.
>
> It is true - today - that libcap puts things in /lib. Therefore - with today's
> behavior - installing them in /usr/lib and then moving them to /lib seems kind
> of odd.
>
> However, the current method LFS uses is guaranteed to still work even if a
> future chooses to start putting things in /usr/local by default, or any other
> place.
>
> Since the current method incurs no real extra cost, and is more robust, I'd
> ask that we consider leaving things as they are - and indeed, making sure that
> no other packages in LFS are depending on the 'default' location of
> installation of things, when a simple configuration parameter will put them in
> a known location.
Well, if anything changes in the build system, we'll have to adapt: it's what
we do right now: there is a new lib (libpsx), so we have to change the
instructions. Also, it seems they that pkg-config does not like the new .pc
file provided (error: "Name field occurs twice in
'/usr/lib/pkgconfig/libcap.pc'". There is another error actually in this .pc
file:
libdir=/lib64 (we need to pass lib=lib during "make" stage too)
So each upgrade needs adaptation anyway. We may not get it right at first, but
we do tests, and sometimes may end up with an acceptable solution. It's
development... More about the .pc file in next message.
Now, the package doc (in Make.Rules) is clear about the use of prefix=something:
# Autoconf-style prefixes are activated when $(prefix) is defined.
# Otherwise binaries and libraries are installed in /{lib,sbin}/,
# header files in /usr/include/ and documentation in /usr/man/man?/.
# These choices are motivated by the fact that getcap and setcap are
# administrative operations that could be needed to recover a system.
It would be a major change in spirit if upstream would move to some other
default, so I doubt they will (I may be proven wrong of course).
Note that our previous instructions did not move the binaries to /sbin, which
is kind of weird in view of the comment above...
As of whether we should rely or not on the defaults, there are a lot of places
where we do rely on defaults, as Ken said in another thread, so one more, one
less, it does not change much...
Pierre
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
