Re: Dump commands

Am 15.08.26 um 12:21 schrieb Pierre Labastie ([email protected]
via lfs-support Mailing List):
> On Sat, 2026-08-15 at 11:22 +0200, Rainer Fiebig wrote:
>> Am 13.08.26 um 18:47 schrieb Bruce Dubbs ([email protected] via
>> lfs-support Mailing List):
>>> On 8/13/26 5:58 AM, Rainer Fiebig ([email protected] via lfs-support
>>> Mailing List) wrote:
>>>> Am 13.08.26 um 03:41 schrieb Bruce Dubbs
>>>> ([email protected] via
>>>> lfs-support Mailing List):
>>>>> On 8/12/26 2:51 PM, Pocket ([email protected] via lfs-
>>>>> support
>>>>> Mailing List) wrote:
>>>>>>
>>>>
>>>> / snip /
>>>>
>>>>>> case $(uname -m) in
>>>>>>     x86_64) chown -v lfs
>>>>>>    $LFS/lib64 ;;
>>>>>> esac
>>>> / snip /
>>>>
>>>> Successful execution of
>>>>
>>>>     chown -v lfs $LFS/lib64
>>>>
>>>> does not depend on whether the machine is x86_64 or not but
>>>> whether
>>>> directory "$LFS/lib64" exists or not.  That directory was already
>>>> created (or not) in ch. 4.2:
>>>>
>>>> case $(uname -m) in
>>>>    x86_64) mkdir -pv $LFS/lib64 ;;
>>>> esac
>>>>
>>>> So the test in ch. 4.3 should _not_ be
>>>>
>>>> case $(uname -m) in ...
>>>>
>>>> but rather
>>>>
>>>> if [[ -d $LFS/lib64 ]]; then
>>>>     chown -v lfs $LFS/lib64
>>>> fi
>>>>
>>>> Apart from that I'm not sure whether using multi-way decision-
>>>> test
>>>> "case" for a one-way test is really a good choice for an
>>>> educational
>>>> project.  At least not without a default case.
>>>>
>>>> BTW: I think that the dot after the last digit in chapter-
>>>> headings like
>>>>     4.3. Adding the LFS User
>>>> is wrong or at least quite unusual.
>>>
>>> I agree with you Rainer on both issues. However they are fairly
>>> minor
>>> issues and I do not want to address them right now due to the
>>> workload
>>> for release.  If we get ahead of the testing we might be able to
>>> adjust
>>> those but they will be low priority.
>>
>> Right, there is no need for speed in these matters.  After the
>> release
>> would be appropriate.  But "low priority"? I'm not so sure about
>> that.
>>
>>>
>>> For the case vs if issue, there are several places where that's
>>> done. 
>>> They have been in place for many years and are known to work.
>>
>> Well, "We've always done it this way" is not a really convincing
>> argument.  Or is it? ;)
>>
>> In this particular "case", testing again for x86_64 instead of
>> $LFS/lib64 in ch. 4.3 goes against the flow of instructions in the
>> book
>> and doesn't make much sense.
> 
> I don't agree. The logic is that the next instruction has to be run
> only if the machine is 64 bit. How the test is done, using uname or the
> presence of $LFS/lib64 is a matter of taste and both can make sense.

Can't agree here.  The test for x86_64 had already been made in ch. 4.2.
 Depending on the outcome, /lib64 was created or not.  Testing again for
x86_64 in ch. 4.3 is therefore redundant and should not be the criterium
for executing (or not) "chown -v lfs $LFS/lib64".

> 
[ snip ]
> 
>>
>>>
>>> For the dot after the section numbering the issue is purely
>>> cosmetic and
>>> would require a change to the appropriate stylesheet.
>>
>> Cosmetics matter - just take the boom in plastic surgery as an
>> indication.  But seriously: the heading-numbering is plain wrong and
>> ugly - that it has gone unnoticed for so long doesn't make it any
>> better.  To me it seems somewhat unworthy of a standard work in the
>> Linux world.  And I think that removing a dot from a stylesheet vs.
>> correct headings provides an uncommonly favourable cost/benefit
>> ratio.
> 
> The only problem is to dig into stylesheets which are modifications of
> docbook-xsl stylesheets written in 2006 or so...

Perhaps it's more complicated than I thought.  But I assumed there would
be only one stylesheet for the headings, namely "lfs-titles.xsl".  Or
are there really several stylesheets for headings?  That would seem
strangely complex to me.

Rainer

-- 
http://lists.linuxfromscratch.org/sympa/info/lfs-support
Unsubscribe: See the above information page