GNU bug report logs - #33573
--add-missing --copy should replace symlinks with real files

Previous Next

Full log

View this message in rfc822 format

From: Bogdan <bogdro_rep <at> gmx.us>
To: Karl Berry <karl <at> freefriends.org>
Cc: automake-patches <at> gnu.org
Subject: bug#33573: Patch to replace symlinks with files
Date: Sat, 31 Dec 2022 20:20:40 +0100

Karl Berry <karl <at> freefriends.org>, Sat Dec 31 2022 03:30:42 GMT+0100 
(Central European Standard Time)
> Hi Bogdan,
> 
>      Someone reported a bug for this, so I simply gave it a try.
> 
> Thank you! I didn't realize you were working on some of the old bugs.
> That is great!


:)


> To bring this one in particular to fruition: can you check what happens
> when -c -a would need to overwrite a symlink? I think it should just
> give a warning. Then the user can decide what to do.


It simply doesn't do or say anything, because the object already 
exists (the subroutine simply leaves).


$ rm -f doc/texinfo.tex
$ automake --add-missing
doc/Makefile.am:1: installing 'doc/texinfo.tex'
$ ll doc/texinfo.tex
lrwxrwxrwx 1 bogdan bogdan 36 gru 31 19:48 doc/texinfo.tex -> 
/usr/share/automake-1.16/texinfo.tex
$ automake --add-missing --copy
$



> And, can you check that automake -a -f -c does in fact overwrite a
> symlink with a copy? And, I guess, that -a -f, without the -c,
> overwrites files with symlinks? (Or, if it gives an error now, that's ok
> too.)


The combination '-a -f -c' does what's expected (replaces a symlink 
with a regular file):


$ ll doc/texinfo.tex
lrwxrwxrwx 1 bogdan bogdan 36 gru 31 19:48 doc/texinfo.tex -> 
/usr/share/automake-1.16/texinfo.tex
$ automake --add-missing --copy
$ automake --add-missing --copy --force-missing
$ ll doc/texinfo.tex
-rw------- 1 bogdan bogdan 374230 gru 31 19:49 doc/texinfo.tex
$


That's where my idea about updating the documentation comes from - may 
not be clear enough.

Just '-a -f' does indeed replace regular files with symlinks:

$ ll doc/texinfo.tex
-rw------- 1 bogdan bogdan 374230 gru 31 19:49 doc/texinfo.tex
$ automake --add-missing --force-missing
$ ll doc/texinfo.tex
lrwxrwxrwx 1 bogdan bogdan 36 gru 31 19:51 doc/texinfo.tex -> 
/usr/share/automake-1.16/texinfo.tex
$


$ automake --version
automake (GNU automake) 1.16.5


> And that the test checks this stuff?


 The change I'm implementing is tested by the test I've added. It 
simply checks if after --copy the file is not a link:

$AUTOMAKE --add-missing --copy
test ! -h texinfo.tex || exit 1


(unneeded parts removed)


> Sorry, but these are the kinds of nitty-gritty things that every
> automake change needs to think about.


Yes, testing and portability is important, I know.



>      Just maybe make something clearer in the documentation and/or the help
>      message in such case, like:
> 
> Yes, agreed. No problem there.
> 
>      I'm not subscribed
> 
> If you intend to keep working for a while on automake (I hope so), you
> should subscribe to the mailing lists, especially bug-automake and
> automake-patches. Unfortunately the debbugs software does not send mail
> to everyone who has been on a given bug (not even the bug originator),
> but only to the associated mailing list, as I understand it.


I see. We'll see what my future work on Automake will look like. Maybe 
I could contribute something useful. Right now, I'm planning just one 
more patch ("the last this year" - yes, it's still 2022 here :) ) and 
later we'll see what time allows. I also have my own projects to look 
after once in a while :).

Some guide like "to implement this and this, you need to change/add 
subroutine that and that" would be nice for beginners.

I wish there would be some kind of roadmap or a list of interesting 
ideas to-do in Automake. The "PLANS" doesn't have much, not for me, at 
least... Otherwise, I don't know if e.g. Automake 2.0 is implemented 
in 99% already or is it maybe just 1% and a full re-write is planned.



> For the same reason, it is good to explicitly cc a bug's originator and
> anyone else who has contributed to the bug, if you happen to have them.


I didn't want to send any notifications to the bugs in case my patches 
get rejected for some reason (like they don't work on *BSD/some 
antique Unix, don't match the programming style, etc., or are 
completely against the idea).

Furthermore, Automake doesn't get so many releases, as I see, so even 
implementing a fix doesn't mean that it will go to a release any time 
soon.



>      and I didn't see them in the mailing list's archive :).
> 
> I see all your messages there now, I believe:
> https://lists.gnu.org/archive/html/bug-automake/2022-12/threads.html
> 
> As I recall, there is a delay of up to an hour or maybe more before the
> archives are updated. Unfortunately it does not happen when a message is
> received; there's a separate polling cron job :(.


Right. They're there. Unfortunately, the Automake website points to 
https://lists.gnu.org/archive/html/automake-patches/ instead :). 
That's also where I send my mails to, not knowing they end up in 
"bug-automake". Minor issue, but may be confusing, as you can see :).

Thanks.

-- 
Regards - Bogdan ('bogdro') D.                 (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):    http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft  http://bogdro.evai.pl/soft4asm
www.Xiph.org  www.TorProject.org  www.LibreOffice.org  www.GnuPG.org

Previous Next

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