Currently the 'location' option supports regular paths only. Then, if user is using SquashFS image as a backend for portage repository, he needs to take care of mounting it himself and remounting whenever the image is updated. For example, I update the image via scp using a non-root user. Therefore, remounting the image after the update is PITA for me. What I'd really prefer is being able to specify the SquashFS image path and expect portage to handle it like an unpacked repository. During the run, portage would mount a local instance of the SquashFS and use it for the build. Afterwards, it would unmount it. The advantages of that are: - less administrative mayhem -- user just has to specify the path to the file without playing with mounts, - after replacing the SquashFS image with a newer one, user doesn't have to remount it by hand --- portage will mount the new image next time it is invoked, - portage will use a consistent tree even when the image is updated --- since it would have the old file mounted :).
I am not sure whether I like the idea to build this into portage: This requires root permissions; I am aware that there is squashfuse but besides of speed issues these things actually *should* be done as root: If something goes wrong or the user changes into the mounted directory while portage is running (which usually can take a long time) umounting can fail. (umount --lazy is not a good idea either: it can block umounting other filesystems on shutdown anyway - I have very bad experience with it in my squash_dir and squashmount projects [in the mv overlay] and use --lazy only as a fallback, and often it causes problems on shutdown if this fallback is needed.) Also there can be troubles with parallel runs of portage and/or other tools: For instance, equery, portage-utils, eix-update would have to do the mounting/umounting game, too, so one would at least need a properly documented global locking mechanism for all related tools. Apart from the IMHO severe security issue that this means that tools like eix-update then cannot drop their permissions: What happens if one tool crashes and does not properly unlock/umount? I would consider it more reasonable to do the mounting in /etc/fstab properly and to write one script which updates the squashfile and simultaneously remounts. This way, the data is always available (so the user can always read the current portage tree when he wants to check something) and mounting/umounting is reduced to the one instance when it is really necessary and useful. Users of systemd or automount can also save the minimal amount of time of mounting the squashfile during boot if they do not run portage. IMHO this is the unix way of doing things: Using existing tools and mechanism instead of rebuilding a complex thing into every tool needing to access the tree.
yeah, portage shouldn't really be in the business of mounting file systems
I concur with vapier. -A
