chicken-install should rm shared libraries prior to install

[Jim Ursetto]

So that I don't forget about it:

chicken-installing an extension that is currently in use will generally cause a segfault in the running program, because the shared lib changes out from under us. If we rm the shared lib first, the old file is disconnected from the filesystem but still available to the program, and we can install the new library, which will be picked up once the program is restarted.

Behavior on windows systems is unknown but should not make things worse.

[Mario Domenech Goulart]

Fixed by 91cc29dfe22f1bded11fa4fec0389857df7b26d0

[Mario Domenech Goulart]

c6d6cd1b153c39ae4191d52193c8da853ddb9a08 reverts 91cc29dfe22f1bded11fa4fec0389857df7b26d0, since it was causing problems.

[sjamaan]

Perhaps we could use BSD install(1) instead of cp(1) in the setup-api. This will not overwrite but unlink (it is explicitly designed to be able to replace "busy text files", ie program binaries that are mapped by currently running processes)

Our install-extension (shared library), install-program and install-script map reasonably well to the various things install(1) knows about. We could use (but not necessarily) (some of) the definitions from the makefiles, ie INSTALL_PROGRAM with its INSTALL_PROGRAM_SHARED_LIBRARY_OPTIONS and INSTALL_PROGRAM_EXECUTABLE_OPTIONS.

[sjamaan]

OTOH, if an extension is reinstalled, its list of files may have changed, so perhaps it's safest to uninstall cleanly first, regardless.

[Mario Domenech Goulart]

In case of reinstallation, chicken-install could obtain the list of current installed files by egg by inspecting the .setup-info file before overwriting it. Then only remove files in the old version (installed) but not in the new version (to be installed).

However, I'm not sure this strategy would work for eggs which don't use install-{extension,program,script} from setup-api.

[sjamaan]

Replying to mario:

In case of reinstallation, chicken-install could obtain the list of current installed files by egg by inspecting the .setup-info file before overwriting it. Then only remove files in the old version (installed) but not in the new version (to be installed).

That would solve the problem I mentioned, but not the original problem in this ticket: segfaults would still happen for shared objects that get replaced. Unless of course we implement both ideas: uninstall the stale files and use BSD install(1) to install the changed and new ones.

However, it's probably easier to just uninstall completely first and then (re)install.

However, I'm not sure this strategy would work for eggs which don't use install-{extension,program,script} from setup-api.

chicken-uninstall has to work for those eggs, doesn't it? When invoking chicken-install foo, it should be able to first uninstall that egg (if there), and then install it. Perhaps try to fetch it first?

The annoying bit would be that if the egg doesn't compile correctly, you'd end up with the egg uninstalled and an uninstallable new version... This idea is getting less and less interesting the more I think about it :)

I guess just replacing cp with install should suffice for now.

[sjamaan]

Too hairy and might break too much if we try to fix it this late in the process

[sjamaan]

If we do decide to rework chicken-install for CHICKEN 5, we should take this into account.

[sjamaan]

Marking it as hard because our first attempt failed hard, and it's part of a complete rework.

[sjamaan]

hurrah, the new chicken-install's generated shell scripts do exactly this.