Brian Dolbec <dol...@gentoo.org> wrote: > Martin Vaeth <mar...@mvath.de> wrote: >> >> However, currently this does not play nicely with squashdelta: >> You have to "undo" the mounting of squashdelta and have to use >> different command (e.g. squashmount) afterwards. > > No, that is not correct [...] > 2) /etc/portage/repo.postsync.d
I know about this hook, but this is not what I meant. What I meant is the possibility to *replace* the automatic mounting of portage by a different command (for instance, a possibility to *avoid* that portage mounts/umounts automatically but expects this to happens in this hook). I give reasons for this below. (This discussion belongs actually to portage-devel mailing list or to some bug, but now I feel the necessity to clarify the misunderstanding.) It is not only inefficient and hackish (with possible problems in case of unexpected situations like a SIGINT or other signal at a "bad" time) if two programs/scripts "fight" about mounts and undo each others' mounts. It also causes severe difficulties in connection with overlayfs/aufs/...: With these filesystems, you must create two (in case of overlayfs even three) auxiliary directories, and in this situation, it might be natural to choose these as temporary direcories (e.g. generated in /tmp with unique names); to understand the following explanation note also that two of these directories (the squash filesystem and the overlay filesystem) should "normally" always be mounted/umounted together. Now if portage umounts only the "overlay" directory, the information about the temporary directory names is lost (leaving possibly quite a bit data in /tmp undeleted forever), and the second necessary "umount" does not happen and is hard to do later on: It prevents the space of the old squash file from actually being freed (and this mount is hard to find later on: It is a mount of a deleted file on an unknown temporary directory. Of course, one could try to find this mount by some heuristic, but this is extremely hackish, and the heuristic might find some other squash file which the user has mounted similarly for some other reason.) In case of the mentioned "squashmount" tool, the situation is better, because "squashmount" is rather complex and e.g. stores/manages the names of temporary directories independently. However, users might also want to use less sophisticated tools than "squashmount" (and also "squashmount" has no easy solution for "random" remounts of the mount points it manages, because it is almost impossible to write a "generic" such solution.) In any case, it is rather hackisch to write a lot of additional code to "undo" an actually undesired umounting+mounting: The "clean" solution appears to be to not do the "undesired" (in this situation) umounting+mounting in the first place but to execute *only* the actually desired (u)mount command(s) instead.
