Re: [lfs-support] New directory layout and FHS 3.0

[Douglas R. Reno]

On Thu, Dec 29, 2016 at 12:59 AM, Hazel Russman 
wrote:

> On Wed, 28 Dec 2016 23:47:45 +0100
> Frans de Boer  wrote:
>
> > I have said that I will forward some patches to get rid of the
> > [...]/lib64 notions after I have tested my older patches against the
> > newest sources.
> >
> > I have created several source code changes and tested them, only to find
> > out that glibc, gcc, libcap and perl have at some places hard coded the
> > path to [...]/lib64 if an x86_64 machine is detected. I can change most
> > of it with good result.
> >
> > Still I do not send the changes yet because I am more and more convinced
> > that on machines with multiarch capabilities one should always use a
> > qualifier in the directory name for libraries.
> > Now, LFS is about teaching others how to start building your own
> > operating system and minimal support utilities. The project started out
> > in the era of 32-bit machines, adopted the 64-bit machine on the fly by
> > use of links to legacy library directories who's naming is no longer
> > discriminatory any more. What if we slip into the 128-bit (or +64-bit)
> > era? Still using the legacy [...]/lib notion?
> > The mail list has already many questions about the naming, maybe time to
> > step into the current reality?
> >
> > Looking at production machines, with current UNIX and Linux
> > distributions, many of them are already using a schema which
> > differentiate already between bit sizes.
> > Currently, I have a conversation on the FHS mailing list of due to the
> > ambiguous nature of qualifiers.
> >
> > A snippet from the latest mail exchange:
> > That said, I can appreciate also the idea that on hardware capable of
> > handling multiple architectures - read size of data paths - you always
> > use qualifiers, regardless if only one or multiple library directories
> > are used. So my previous second proposal is then augmented into:
> >
> >[/usr[/local]]/lib for each different set of libraries
> >
> > For compatibility one should also add
> >[/usr/[/local]]/lib -> [/usr[/local]]/lib
> >Where .../lib links to the library directory supporting the native bit
> >size.
> >
> > This implies that on 32-bit intel like systems, you always have a
> > [...]/lib32 directory, an optional [...]/lib16 and [...]/lib is a link
> > to [...]/lib32.
> > On 64-bit Intel like systems you have [...]/lib64, an optional
> > [...]/lib<32|16> and [...]/lib is a link to [...]/lib64.
> >
> > The above schema is already in widespread use on 64-bit machines, with
> > the exception of the legacy use of [...]/lib for 32-bit library
> directories.
> > Also, modification of sources for glibc, gcc, libcap, perl etc, are not
> > needed anymore. Due to the fact that some of these packages are core
> > packages and it would require a lot of effort for the maintainers to
> > change their current hard coded assumptions into more flexible code.
> > ---
> >
> > I wait to see where this all is going before I decide what to do with
> > the current patches. Note that there are more patches required then
> > currently given in the LFS development branch.
> >
> > Regards, Frans.
>
>
> Will this change do away with the very annoying screens of warning
> messages from package libtool scripts about libraries seemingly having
> moved? I'm sure I'm not the only person who finds them off-putting.
> --


Our current setup (thanks to DJ) gets rid of them entirely. I haven't seen
a single one
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] New directory layout and FHS 3.0

[Frans de Boer]

On 29-12-16 07:59, Hazel Russman wrote:

On Wed, 28 Dec 2016 23:47:45 +0100
Frans de Boer  wrote:


I have said that I will forward some patches to get rid of the
[...]/lib64 notions after I have tested my older patches against the
newest sources.

I have created several source code changes and tested them, only to find
out that glibc, gcc, libcap and perl have at some places hard coded the
path to [...]/lib64 if an x86_64 machine is detected. I can change most
of it with good result.

Still I do not send the changes yet because I am more and more convinced
that on machines with multiarch capabilities one should always use a
qualifier in the directory name for libraries.
Now, LFS is about teaching others how to start building your own
operating system and minimal support utilities. The project started out
in the era of 32-bit machines, adopted the 64-bit machine on the fly by
use of links to legacy library directories who's naming is no longer
discriminatory any more. What if we slip into the 128-bit (or +64-bit)
era? Still using the legacy [...]/lib notion?
The mail list has already many questions about the naming, maybe time to
step into the current reality?

Looking at production machines, with current UNIX and Linux
distributions, many of them are already using a schema which
differentiate already between bit sizes.
Currently, I have a conversation on the FHS mailing list of due to the
ambiguous nature of qualifiers.

A snippet from the latest mail exchange:
That said, I can appreciate also the idea that on hardware capable of
handling multiple architectures - read size of data paths - you always
use qualifiers, regardless if only one or multiple library directories
are used. So my previous second proposal is then augmented into:

   [/usr[/local]]/lib for each different set of libraries

For compatibility one should also add
   [/usr/[/local]]/lib -> [/usr[/local]]/lib
   Where .../lib links to the library directory supporting the native bit
   size.

This implies that on 32-bit intel like systems, you always have a
[...]/lib32 directory, an optional [...]/lib16 and [...]/lib is a link
to [...]/lib32.
On 64-bit Intel like systems you have [...]/lib64, an optional
[...]/lib<32|16> and [...]/lib is a link to [...]/lib64.

The above schema is already in widespread use on 64-bit machines, with
the exception of the legacy use of [...]/lib for 32-bit library directories.
Also, modification of sources for glibc, gcc, libcap, perl etc, are not
needed anymore. Due to the fact that some of these packages are core
packages and it would require a lot of effort for the maintainers to
change their current hard coded assumptions into more flexible code.
---

I wait to see where this all is going before I decide what to do with
the current patches. Note that there are more patches required then
currently given in the LFS development branch.

Regards, Frans.



Will this change do away with the very annoying screens of warning messages 
from package libtool scripts about libraries seemingly having moved? I'm sure 
I'm not the only person who finds them off-putting.

As far as I have seen, they only appear when creating the target 
binaries. So it is just a minor issue, I guess. But to give a straight 
answer to your question: I don't know yet. I will change the layout 
(again) and test everything. I don't expect any difficulty or bump since 
the proposed layout is very similar to what was used under LFS. The only 
real change is that links and directories switch contents.


We should also not forget to preserve the purpose of LFS in the first 
place. A means to get familiar of building a own Linux OS. There is - in 
my view - a need to get closer to real world examples and therefor be 
done with library directory names originating from the 16/32-bit era.


--- Frans.
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] New directory layout and FHS 3.0

[Hazel Russman]

On Wed, 28 Dec 2016 23:47:45 +0100
Frans de Boer  wrote:

> I have said that I will forward some patches to get rid of the 
> [...]/lib64 notions after I have tested my older patches against the 
> newest sources.
> 
> I have created several source code changes and tested them, only to find 
> out that glibc, gcc, libcap and perl have at some places hard coded the 
> path to [...]/lib64 if an x86_64 machine is detected. I can change most 
> of it with good result.
> 
> Still I do not send the changes yet because I am more and more convinced 
> that on machines with multiarch capabilities one should always use a 
> qualifier in the directory name for libraries.
> Now, LFS is about teaching others how to start building your own 
> operating system and minimal support utilities. The project started out 
> in the era of 32-bit machines, adopted the 64-bit machine on the fly by 
> use of links to legacy library directories who's naming is no longer 
> discriminatory any more. What if we slip into the 128-bit (or +64-bit) 
> era? Still using the legacy [...]/lib notion?
> The mail list has already many questions about the naming, maybe time to 
> step into the current reality?
> 
> Looking at production machines, with current UNIX and Linux 
> distributions, many of them are already using a schema which 
> differentiate already between bit sizes.
> Currently, I have a conversation on the FHS mailing list of due to the 
> ambiguous nature of qualifiers.
> 
> A snippet from the latest mail exchange:
> That said, I can appreciate also the idea that on hardware capable of 
> handling multiple architectures - read size of data paths - you always 
> use qualifiers, regardless if only one or multiple library directories 
> are used. So my previous second proposal is then augmented into:
> 
>[/usr[/local]]/lib for each different set of libraries
> 
> For compatibility one should also add
>[/usr/[/local]]/lib -> [/usr[/local]]/lib
>Where .../lib links to the library directory supporting the native bit
>size.
> 
> This implies that on 32-bit intel like systems, you always have a 
> [...]/lib32 directory, an optional [...]/lib16 and [...]/lib is a link 
> to [...]/lib32.
> On 64-bit Intel like systems you have [...]/lib64, an optional 
> [...]/lib<32|16> and [...]/lib is a link to [...]/lib64.
> 
> The above schema is already in widespread use on 64-bit machines, with 
> the exception of the legacy use of [...]/lib for 32-bit library directories.
> Also, modification of sources for glibc, gcc, libcap, perl etc, are not 
> needed anymore. Due to the fact that some of these packages are core 
> packages and it would require a lot of effort for the maintainers to 
> change their current hard coded assumptions into more flexible code.
> ---
> 
> I wait to see where this all is going before I decide what to do with 
> the current patches. Note that there are more patches required then 
> currently given in the LFS development branch.
> 
> Regards, Frans.


Will this change do away with the very annoying screens of warning messages 
from package libtool scripts about libraries seemingly having moved? I'm sure 
I'm not the only person who finds them off-putting.
-- 

H Russman
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] New directory layout and FHS 3.0

[Frans de Boer]

On 21-12-16 17:48, Bruce Dubbs wrote:

Frans de Boer wrote:

On 20-12-16 23:02, Bruce Dubbs wrote:

Frans de Boer wrote:

On 20-12-16 21:56, Bruce Dubbs wrote:

Frans de Boer wrote:

Hi all,

I just noticed that there are changes in the development version of
LFS,
related to x86_64 architecture. But i do miss the rationale and/or
more
explanation. The latter is important because I see several changes
which
make sense, but misses other related changes in various other
packages.
Also having now /lib64 as a directory instead of a link puzzles
me. The
more because /lib is still a directory and not a link to /lib64 as
per
FHS
3.0.


Where does FHS 3.0 say a symlink is required?

What additional explanation would you suggest and where should it be?


Looking at the FHS 3.0 documentation does not help either since
the new
LFS directory structure seems to be a non-consistent mix of various
possibilities. See above and next example: /usr/lib with redundant
link
/usr/lib64.


4.8. /usr/lib : Alternate format libraries (optional)

does not seem to require /usr/lib64.



Footnote 13 makes an implicit reference to it. But I admit, it's not a
very strong point.

However, it seems not consistent to have /usr/lib and in the root
/lib64.
Use of qualifiers is - as I read it - only meant to be use by
multi-library systems, which LFS explicitly states currently that it
is not.


That's right, but there are apps that hard code some assumptions so
/lib64 with its two symlinks is a workaround.  If we could reliably
remove it, we would.


Also, I never implied that having /lib64 does require /usr/lib64 -
simply
because there is no hard relation between them or their content. It's
just
what I stated above, inconsistent use of qualifiers.


OK, but we do't need /usr/lib64 and not having it makes things easier
for us (for the most part).


By the way: Having /lib64 and /usr/lib64 as links to their
respective lib
directory make sense only when using third party (binary) packages.


Agree for the most part.  Some packages require a patch to avoid the
need and finding where the changes are needed is often difficult.


Finally on the matter of explanation: sure, I can write one and find a
place to put it up. But we first need to get into the "inconsistency"
issue to be able to make a coherent and justifiable explanation.


As I said, it is a workaround.  I'd prefer that it was not needed.

Even with our changes, look at the adjsuting page in Chapter 6:

echo 'int main(){}' > dummy.c
cc dummy.c -v -Wl,--verbose &> dummy.log
readelf -l a.out | grep ': /lib'

  [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]

I'm not sure if that /lib64 is in glibc or binutils (probably glibc),
but it would need to be fixed to remove /lib64.



I will send the needed patches I made in the past for other packages.
Thus
eliminating the need in LFS for qualified library directories.

I have, however, not used those for some time, which needs therefor some
(re)testing. Due to the coming holidays, I guess I can send them in
sometime next week (to the bug-list?).


We can review these packages whenever you send them, but we will want to
be careful as we get ready for the next (8.0) release.

  -- Bruce


I have said that I will forward some patches to get rid of the 
[...]/lib64 notions after I have tested my older patches against the 
newest sources.


I have created several source code changes and tested them, only to find 
out that glibc, gcc, libcap and perl have at some places hard coded the 
path to [...]/lib64 if an x86_64 machine is detected. I can change most 
of it with good result.


Still I do not send the changes yet because I am more and more convinced 
that on machines with multiarch capabilities one should always use a 
qualifier in the directory name for libraries.
Now, LFS is about teaching others how to start building your own 
operating system and minimal support utilities. The project started out 
in the era of 32-bit machines, adopted the 64-bit machine on the fly by 
use of links to legacy library directories who's naming is no longer 
discriminatory any more. What if we slip into the 128-bit (or +64-bit) 
era? Still using the legacy [...]/lib notion?
The mail list has already many questions about the naming, maybe time to 
step into the current reality?


Looking at production machines, with current UNIX and Linux 
distributions, many of them are already using a schema which 
differentiate already between bit sizes.
Currently, I have a conversation on the FHS mailing list of due to the 
ambiguous nature of qualifiers.


A snippet from the latest mail exchange:
That said, I can appreciate also the idea that on hardware capable of 
handling multiple architectures - read size of data paths - you always 
use qualifiers, regardless if only one or multiple library directories 
are used. So my previous second proposal is then augmented into:


  [/usr[/local]]/lib for each different set of libraries

For compatibility one 

Re: [lfs-support] New directory layout and FHS 3.0

[Bruce Dubbs]

Frans de Boer wrote:

On 20-12-16 23:02, Bruce Dubbs wrote:

Frans de Boer wrote:

On 20-12-16 21:56, Bruce Dubbs wrote:

Frans de Boer wrote:

Hi all,

I just noticed that there are changes in the development version of
LFS,
related to x86_64 architecture. But i do miss the rationale and/or more
explanation. The latter is important because I see several changes
which
make sense, but misses other related changes in various other packages.
Also having now /lib64 as a directory instead of a link puzzles me. The
more because /lib is still a directory and not a link to /lib64 as per
FHS
3.0.


Where does FHS 3.0 say a symlink is required?

What additional explanation would you suggest and where should it be?


Looking at the FHS 3.0 documentation does not help either since the new
LFS directory structure seems to be a non-consistent mix of various
possibilities. See above and next example: /usr/lib with redundant link
/usr/lib64.


4.8. /usr/lib : Alternate format libraries (optional)

does not seem to require /usr/lib64.



Footnote 13 makes an implicit reference to it. But I admit, it's not a
very strong point.

However, it seems not consistent to have /usr/lib and in the root /lib64.
Use of qualifiers is - as I read it - only meant to be use by
multi-library systems, which LFS explicitly states currently that it
is not.


That's right, but there are apps that hard code some assumptions so
/lib64 with its two symlinks is a workaround.  If we could reliably
remove it, we would.


Also, I never implied that having /lib64 does require /usr/lib64 - simply
because there is no hard relation between them or their content. It's
just
what I stated above, inconsistent use of qualifiers.


OK, but we do't need /usr/lib64 and not having it makes things easier
for us (for the most part).


By the way: Having /lib64 and /usr/lib64 as links to their respective lib
directory make sense only when using third party (binary) packages.


Agree for the most part.  Some packages require a patch to avoid the
need and finding where the changes are needed is often difficult.


Finally on the matter of explanation: sure, I can write one and find a
place to put it up. But we first need to get into the "inconsistency"
issue to be able to make a coherent and justifiable explanation.


As I said, it is a workaround.  I'd prefer that it was not needed.

Even with our changes, look at the adjsuting page in Chapter 6:

echo 'int main(){}' > dummy.c
cc dummy.c -v -Wl,--verbose &> dummy.log
readelf -l a.out | grep ': /lib'

  [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]

I'm not sure if that /lib64 is in glibc or binutils (probably glibc),
but it would need to be fixed to remove /lib64.



I will send the needed patches I made in the past for other packages. Thus
eliminating the need in LFS for qualified library directories.

I have, however, not used those for some time, which needs therefor some
(re)testing. Due to the coming holidays, I guess I can send them in
sometime next week (to the bug-list?).


We can review these packages whenever you send them, but we will want to 
be careful as we get ready for the next (8.0) release.


  -- Bruce


--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] New directory layout and FHS 3.0

[Frans de Boer]

On 20-12-16 23:02, Bruce Dubbs wrote:

Frans de Boer wrote:

On 20-12-16 21:56, Bruce Dubbs wrote:

Frans de Boer wrote:

Hi all,

I just noticed that there are changes in the development version of
LFS,
related to x86_64 architecture. But i do miss the rationale and/or more
explanation. The latter is important because I see several changes
which
make sense, but misses other related changes in various other packages.
Also having now /lib64 as a directory instead of a link puzzles me. The
more because /lib is still a directory and not a link to /lib64 as per
FHS
3.0.


Where does FHS 3.0 say a symlink is required?

What additional explanation would you suggest and where should it be?


Looking at the FHS 3.0 documentation does not help either since the new
LFS directory structure seems to be a non-consistent mix of various
possibilities. See above and next example: /usr/lib with redundant link
/usr/lib64.


4.8. /usr/lib : Alternate format libraries (optional)

does not seem to require /usr/lib64.



Footnote 13 makes an implicit reference to it. But I admit, it's not a
very strong point.

However, it seems not consistent to have /usr/lib and in the root /lib64.
Use of qualifiers is - as I read it - only meant to be use by
multi-library systems, which LFS explicitly states currently that it
is not.


That's right, but there are apps that hard code some assumptions so
/lib64 with its two symlinks is a workaround.  If we could reliably
remove it, we would.


Also, I never implied that having /lib64 does require /usr/lib64 - simply
because there is no hard relation between them or their content. It's
just
what I stated above, inconsistent use of qualifiers.


OK, but we do't need /usr/lib64 and not having it makes things easier
for us (for the most part).


By the way: Having /lib64 and /usr/lib64 as links to their respective lib
directory make sense only when using third party (binary) packages.


Agree for the most part.  Some packages require a patch to avoid the
need and finding where the changes are needed is often difficult.


Finally on the matter of explanation: sure, I can write one and find a
place to put it up. But we first need to get into the "inconsistency"
issue to be able to make a coherent and justifiable explanation.


As I said, it is a workaround.  I'd prefer that it was not needed.

Even with our changes, look at the adjsuting page in Chapter 6:

echo 'int main(){}' > dummy.c
cc dummy.c -v -Wl,--verbose &> dummy.log
readelf -l a.out | grep ': /lib'

  [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]

I'm not sure if that /lib64 is in glibc or binutils (probably glibc),
but it would need to be fixed to remove /lib64.

  -- Bruce
I will send the needed patches I made in the past for other packages. 
Thus eliminating the need in LFS for qualified library directories.


I have, however, not used those for some time, which needs therefor some 
(re)testing. Due to the coming holidays, I guess I can send them in 
sometime next week (to the bug-list?).


--- Frans.
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] New directory layout and FHS 3.0

[Bruce Dubbs]

Frans de Boer wrote:

On 20-12-16 21:56, Bruce Dubbs wrote:

Frans de Boer wrote:

Hi all,

I just noticed that there are changes in the development version of LFS,
related to x86_64 architecture. But i do miss the rationale and/or more
explanation. The latter is important because I see several changes which
make sense, but misses other related changes in various other packages.
Also having now /lib64 as a directory instead of a link puzzles me. The
more because /lib is still a directory and not a link to /lib64 as per
FHS
3.0.


Where does FHS 3.0 say a symlink is required?

What additional explanation would you suggest and where should it be?


Looking at the FHS 3.0 documentation does not help either since the new
LFS directory structure seems to be a non-consistent mix of various
possibilities. See above and next example: /usr/lib with redundant link
/usr/lib64.


4.8. /usr/lib : Alternate format libraries (optional)

does not seem to require /usr/lib64.



Footnote 13 makes an implicit reference to it. But I admit, it's not a
very strong point.

However, it seems not consistent to have /usr/lib and in the root /lib64.
Use of qualifiers is - as I read it - only meant to be use by
multi-library systems, which LFS explicitly states currently that it is not.


That's right, but there are apps that hard code some assumptions so /lib64 
with its two symlinks is a workaround.  If we could reliably remove it, we 
would.



Also, I never implied that having /lib64 does require /usr/lib64 - simply
because there is no hard relation between them or their content. It's just
what I stated above, inconsistent use of qualifiers.


OK, but we do't need /usr/lib64 and not having it makes things easier for 
us (for the most part).



By the way: Having /lib64 and /usr/lib64 as links to their respective lib
directory make sense only when using third party (binary) packages.


Agree for the most part.  Some packages require a patch to avoid the need 
and finding where the changes are needed is often difficult.



Finally on the matter of explanation: sure, I can write one and find a
place to put it up. But we first need to get into the "inconsistency"
issue to be able to make a coherent and justifiable explanation.


As I said, it is a workaround.  I'd prefer that it was not needed.

Even with our changes, look at the adjsuting page in Chapter 6:

echo 'int main(){}' > dummy.c
cc dummy.c -v -Wl,--verbose &> dummy.log
readelf -l a.out | grep ': /lib'

  [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]

I'm not sure if that /lib64 is in glibc or binutils (probably glibc), but 
it would need to be fixed to remove /lib64.


  -- Bruce





--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] New directory layout and FHS 3.0

[Frans de Boer]

On 20-12-16 21:56, Bruce Dubbs wrote:

Frans de Boer wrote:

Hi all,

I just noticed that there are changes in the development version of LFS,
related to x86_64 architecture. But i do miss the rationale and/or more
explanation. The latter is important because I see several changes which
make sense, but misses other related changes in various other packages.
Also having now /lib64 as a directory instead of a link puzzles me. The
more because /lib is still a directory and not a link to /lib64 as per
FHS
3.0.


Where does FHS 3.0 say a symlink is required?

What additional explanation would you suggest and where should it be?


Looking at the FHS 3.0 documentation does not help either since the new
LFS directory structure seems to be a non-consistent mix of various
possibilities. See above and next example: /usr/lib with redundant link
/usr/lib64.


4.8. /usr/lib : Alternate format libraries (optional)

does not seem to require /usr/lib64.

  -- Bruce


Footnote 13 makes an implicit reference to it. But I admit, it's not a 
very strong point.


However, it seems not consistent to have /usr/lib and in the root 
/lib64. Use of qualifiers is - as I read it - only meant to be use by 
multi-library systems, which LFS explicitly states currently that it is not.


Also, I never implied that having /lib64 does require /usr/lib64 - 
simply because there is no hard relation between them or their content. 
It's just what I stated above, inconsistent use of qualifiers.


By the way: Having /lib64 and /usr/lib64 as links to their respective 
lib directory make sense only when using third party (binary) packages.


Finally on the matter of explanation: sure, I can write one and find a 
place to put it up. But we first need to get into the "inconsistency" 
issue to be able to make a coherent and justifiable explanation.


--- Frans.


--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] New directory layout and FHS 3.0

[Bruce Dubbs]

Frans de Boer wrote:

Hi all,

I just noticed that there are changes in the development version of LFS,
related to x86_64 architecture. But i do miss the rationale and/or more
explanation. The latter is important because I see several changes which
make sense, but misses other related changes in various other packages.
Also having now /lib64 as a directory instead of a link puzzles me. The
more because /lib is still a directory and not a link to /lib64 as per FHS
3.0.


Where does FHS 3.0 say a symlink is required?

What additional explanation would you suggest and where should it be?


Looking at the FHS 3.0 documentation does not help either since the new
LFS directory structure seems to be a non-consistent mix of various
possibilities. See above and next example: /usr/lib with redundant link
/usr/lib64.


4.8. /usr/lib : Alternate format libraries (optional)

does not seem to require /usr/lib64.

  -- Bruce


--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style