Vim 9.1.0224

[sage-etcher]

No description provided.

[Nuc1eoN]

I am getting

cd /usr/bin; ln -s vim gvim
cd /usr/bin; ln -s vim gview
cd /usr/bin; ln -s vim rgvim
cd /usr/bin; ln -s vim rgview
cd /usr/bin; ln -s vim evim
cd /usr/bin; ln -s vim eview
ln: failed to create symbolic link 'gview': File exists
ln: failed to create symbolic link 'gvim': File exists
ln: failed to create symbolic link 'rgvim': File exists
make: *** [Makefile:2706: /usr/bin/gview] Error 1
make: *** Waiting for unfinished jobs....
ln: failed to create symbolic link 'rgview': File exists
ln: failed to create symbolic link 'evim': File exists
make: *** [Makefile:2715: /usr/bin/rgvim] Error 1
make: *** [Makefile:2703: /usr/bin/gvim] Error 1
make: *** [Makefile:2718: /usr/bin/rgview] Error 1
make: *** [Makefile:2727: /usr/bin/evim] Error 1
ln: failed to create symbolic link 'eview': File exists
make: *** [Makefile:2730: /usr/bin/eview] Error 1
chmod 755 /usr/share/vim/vim91/spell
chmod 755 /usr/share/vim/vim91/compiler
chmod 755 /usr/share/vim/vim91/macros
chmod 755 /usr/share/vim/vim91/pack
UnionSandbox: Cleaning up.
UnionSandbox: Moving entries to: /Programs/Vim/9.1.0224/.SandboxInstall_Root
Compile: Installation was moved to /Programs/Vim/9.1.0224-failed
Compile: Vim 9.1.0224 - Installation step failed.

Did you get a similar issue or do you know how to resolve it?

[sage-etcher]

Yes, I had run into the same problem. If you DisableProgram the old version, then Compile the new, the error doesn't show. Initially I had assumed it was related to Compile Bug 51, however on further inspection, that doesn't appear to be the case.
ATM, I'm unsure on how to fix the issue, I'm looking into such as we speak.

[sage-etcher]

Looks like the issue is coming from Vim's src/Makefile. During the Makefile's install sequence many of ln -s commands are not using --force or -f, so if a destination file already exists (such as from a previous version) the command returns an error.

It doesn't appear that either configure nor src/configure are updating the Makefiles, so it should be safe to add a patch for said Makefiles.

As a quick fix I added a patch to make the problem ln -s commands use ln -sf instead. This appears to have fixed the Issue.

[Nuc1eoN]

Ohh great job at getting to the bottom of the issue and providing a patch. I will test later.

Please always remember to mention potential issues in your PRs, or fix them in the recipe (like adding the proper dependencies). On the other hand don't let smaller issues clog up your work cue, just make sure to let us know.

Btw our convention is to enumerate recipe patches like so: 01-..., 02-.... That is also how our automatched recipe patcher AutoPatch would name them. If you have the opportunity check out AutoPatch, it is really neat :)

Lastly, I wonder if this type of bug could (or should) have been prevented by Compile.. @lucasvr do you have any suggestion on this? In my mind - ideally, the new program files should not clash against the old ones?

[Nuc1eoN]

Looks like the issue is coming from Vim's src/Makefile. During the Makefile's install sequence many of ln -s commands are not using --force or -f, so if a destination file already exists (such as from a previous version) the command returns an error.

It doesn't appear that either configure nor src/configure are updating the Makefiles, so it should be safe to add a patch for said Makefiles.

As a quick fix I added a patch to make the problem ln -s commands use ln -sf instead. This appears to have fixed the Issue.

Works great! Merging new Vim.

Lastly, I wonder if this type of bug could (or should) have been prevented by Compile.. @lucasvr do you have any suggestion on this? In my mind - ideally, the new program files should not clash against the old ones?

@lucasvr I'd love to know your opinion on this if you find the time :)