On 08/09/2016 11:47, akhiezer wrote:
From: DJ Lucas <[email protected]>
Date: Thu, 8 Sep 2016 00:53:08 -0500
Subject: [lfs-dev] Removing /lib64 symlink and /usr/lib64 revisited
Okay, now that 7.10 has released, time to bring this up again.
(Is it a little unseemly to jump on this again so immediately after
new-releases announcement.)
This and a few other things have been put on hold because freeze and
release was to close. Now we have six months to discuss those.
This gets rid of the "seems to be moved" messages,
Or fixup the dumbness of the generators of the 'seems to be moved' msgs?
Let's put it the other way around. Upstream do a lot of things we may or
may not agree with (e.g. making gnome systemd only, or making c++14 the
default for C++ code in GCC, etc). But this book is about using upstream
packages, so it has to cope with upstream's decisions. The question is
then: what is the reason to depart from upstream will about lib vs
lib64? At a time, the answer was: because not all packages were able to
cope with it, and the symlink was there to avoid a big mess. Now, this
is not true anymore. We may have other reasons to keep the symlink,
though, but not that one.
as well as a most tests for arch=x86_64.
Not a big deal, shurely?
The /lib64 directory remains for LSB (and other binary)
compatibility. Requires changes to a few CMake packages, as well as
CLang, otherwise, relatively easy. I still haven't tested rebuild of
ada, but did build a significant portion of BLFS (and since we are
following what is already done for CLFS Pure64), seems relatively safe.
Why do you want (seemingly so much) to do such work - not least vs the
above 'moved'/'tests' reasons - and to take b/lfs down that avenue.
Does it make things more awkward for folks who may want to add 32-bit
multilib to a 64-bit build.
Again, the other way around: why would you want to keep the symlink?
Note that we already have a lot of places where we fix install
directories (for docs, mainly, but also for /usr/libexec vs /usr/lib,
&c), What DJ proposes does not add so much.
Pierre
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
