GNU bug report logs - #63161
Issue with mkinstalldirs and symb links

Previous Next

Package: automake;

Reported by: Panaiotis Arnaud <Arnaud.Panaiotis.ext <at> vossloh.com>

Date: Sat, 29 Apr 2023 01:21:01 UTC

Severity: normal

Tags: wontfix

Done: Karl Berry <karl <at> freefriends.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Panaiotis Arnaud <Arnaud.Panaiotis.ext <at> vossloh.com>
Subject: bug#63161: closed (Re: bug#63161: Issue with mkinstalldirs and
 symb links)
Date: Wed, 31 Jan 2024 22:48:05 +0000
[Message part 1 (text/plain, inline)]
Your bug report

#63161: Issue with mkinstalldirs and symb links

which was filed against the automake package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 63161 <at> debbugs.gnu.org.

-- 
63161: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63161
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
From: Karl Berry <karl <at> freefriends.org>
To: Arnaud.Panaiotis.ext <at> vossloh.com
Cc: 63161 <at> debbugs.gnu.org
Subject: Re: bug#63161: Issue with mkinstalldirs and symb links
Date: Wed, 31 Jan 2024 15:47:06 -0700
Hi Arnaud - back on this bug from last April, I guess I just don't think
it's the job of mkinstalldirs to follow symlinks. It feels like too big
a change in behavior. I think the real bug here lies in whatever
created the broken symlink in the first place.

So I'm going to close this one. All the best,
Karl

[Message part 3 (message/rfc822, inline)]
From: Panaiotis Arnaud <Arnaud.Panaiotis.ext <at> vossloh.com>
To: "bug-automake <at> gnu.org" <bug-automake <at> gnu.org>
Subject: Issue with mkinstalldirs and symb links
Date: Fri, 28 Apr 2023 14:29:36 +0000
[Message part 4 (text/plain, inline)]
Hi,

I encounter an issue while working with glibc with script scripts/mkinstalldirs. In scriptversion=2018-03-07.03; # UTC.

I had a symbolic link lib64->lib and the folder lib did not exist.

The glibc installing process is calling   ./scripts/mkinstalldirs [..]/lib64 which failed to mkdir -p it.

I made a working patch for my case, which need to be reworked as a loop (As I use the script with a single argument $@ and not a list of them).

Here is my solution:
--- a/scripts/mkinstalldirs.old 2023-04-28 15:25:12.087611912 +0200
+++ b/scripts/mkinstalldirs     2023-04-28 15:27:28.056402448 +0200
@@ -78,8 +78,13 @@
case $dirmode in
   '')
     if mkdir -p --version . >/dev/null 2>&1 && test ! -d ./--version; then
-      echo "mkdir -p -- $*"
-      exec mkdir -p -- "$@"
+      if test -L "$@"; then
+        echo "mkdir -p -- \"\$(realpath $*)\""
+        exec mkdir -p -- "$(realpath $@)"
+      else
+        echo "mkdir -p -- $*"
+        exec mkdir -p -- "$@"
+      fi
     else
       # On NextStep and OpenStep, the 'mkdir' command does not
       # recognize any option.  It will interpret all options as

Best regards,

Arnaud Panaïotis
Freelance Lead developer
APsudo

[Message part 5 (text/html, inline)]

This bug report was last modified 1 year and 149 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.