executable gawk-5.2.1 is a remnant from Chapter 7

[Xi Ruoyao]

gawk building system codes:

install-exec-hook:
    (cd $(DESTDIR)$(bindir); \
    name=`echo gawk | sed '$(transform)'` ; \
    $(LN) $${name}$(EXEEXT) gawk-$(VERSION)$(EXEEXT) 2>/dev/null ; \
    if [ ! -f awk$(EXEEXT) ]; \
    then    $(LN_S) $${name}$(EXEEXT) awk$(EXEEXT); \
    fi; exit 0)

The line creating gawk-5.2.1 expands to:

ln gawk gawk-5.2.1 2>/dev/null

Note that ln will refuse to recreate gawk-5.2.1 if it already exists. So in Chapter 8, gawk-5.2.1 is not recreated. As it's a hard link (different from symlink), it will keep the old content installed in Chapter 7.

I guess make LN='ln -f' install will fix the issue, but I've not tested it yet.

[Bruce Dubbs]

Also add gawkbug to the installed programs.

[DJ Lucas]

What is the point of the hard link in this case? Perhaps I'm missing something obvious, but even for upstream, I can't see a reason why a hard link would be beneficial. Wouldn't we just want $(LN_S) for the gawk link in both chapters? Now that alone does not actually fix the issue (would hide it), still need to introduce -f, but if we are bugging upstream, might as well have it complete. Also, for 5.2.0 I had the following (normal jhalfs build, no packaging), likely a result of our automated stripping?

dj [ ~ ]$ ls -li /usr/bin/gawk*
4738470 -rwxr-xr-x 1 root root 721248 Nov 22 17:10 /usr/bin/gawk
4724646 -rwxr-xr-x 1 root root 659040 Nov 22 17:10 /usr/bin/gawk-5.2.0
4738471 -rwxr-xr-x 1 root root   6432 Nov 22 17:02 /usr/bin/gawkbug
dj [ ~ ]$ cat /etc/os-release
NAME="Linux From Scratch"
VERSION="r11.2-206"
ID=lfs
PRETTY_NAME="Linux From Scratch r11.2-206"
VERSION_CODENAME="pkguser-jhalfs"

[Xi Ruoyao]

"ln -s" can "fix" the issue: we don't consider a remnant symlink from Chapter 6 or 7 bad if the path is correct (for example, /lib/ld-linux-x86-64.so.2). But having a symlink gawk-5.2.1 -> gawk is wrong IMO: if gawk is updated to 5.2.2, running gawk-5.2.1 will actually invoke 5.2.2 and puzzle people. OTOH we can use gawk -> gawk-5.2.1, but it looks like we have to create this link manually.

[pierre]

I think this is not our role to "fix" upstream choices, even if we don't agree (as long as they do not break our systems or course). Trying to do that would open a can of worms:

• almost all upstream choices are questionable: that makes a lot of packages to examine
• inside the lfs team, I guess it would be hard to reach a consensus on what should be fixed

So for the present case, let's keep a hard link, and use ln -f: this is where we should change upstream's choice: without -f, it "breaks" our system.

[Bruce Dubbs]

Replying to pierre:

So for the present case, let's keep a hard link, and use ln -f: this is where we should change upstream's choice: without -f, it "breaks" our system.

I agree. I think the reason for the gawk-<version> entry is so that it doesn't get removed when a new version is installed. The problem is that it also doesn't get removed if the same version is reinstalled like we do in Chapter 6 and Chapter 8.

I don't know why upstream prefers a hard link to a symbolic link, but we should follow their lead and only remove the file in LFS with the '-f' in Chapter 8. I'll plan on doing that when I update LFS on Thursday.

[Bruce Dubbs]

Fixed at commit c9aabf13a1e8e1fb57688a7dea2f2ca2f1a9e1ab

    Ensure a gawk hard link is updated in Chapter 8.
    Update to iana-etc-20221209.
    Update to vim-9.0.1060.
    Update to iproute2-6.1.0.
    Update to xz-5.4.0.
    Update to bash-5.2.15.
    Update to psmisc-23.6.
    Update to mpc-1.3.0.
    Update to python3-3.11.1.
    Update to procps-ng-4.0.2.

[Xi Ruoyao]

This issue has returned since gawk-5.2.2. Fixed again at r12.0-74-g5f8327e63.