The following commit will make the next baselayout replace all /etc/mtab file with symlinks to make OpenRC to systemd migrations easier: https://gitweb.gentoo.org/proj/baselayout.git/commit/?id=d79832c6b962969c5c57f4ff201c476e34e6789d William Hubbs wants to drop the script from OpenRC because he is only interested in supporting the symlink. However, what determines support for /etc/mtab as a regular file is actually util-linux and glibc. There is no doubt that a symlink to /proc/self/mounts is superior to the old approach of mtab as a file unless you need it for developing cross platform software, but there is no reason to force symlink creation on each baselayout upgrade, which will annoy those who want the old behavior for testing purposes. Dropping the mtab script from OpenRC does not stop users who like the traditional approach from doing it via our own script or the local script and those migrating from OpenRC to systemd will already have to change things, so requiring them to createthe symlink manually should be fine. We could use -f only on the first upgrade when a change from a version that didn't make the symlink is done, rather than *every* upgrade, and then print information about the symlink substitution as einfo. That way this is a one time annoyance for those who want the old behavior and they are informed.
I should probably state that I would prefer to have the symlink made on only new systems, leave the OpenRC mtab script around for old systems and new ones where users want the symlink and let users decide, but William Hubbs is unwilling to do this.
+1. If users configure their system away from the default and use /etc/mtab as a file (for whatever reason), a re-emerge of baselayout shouldn't override their preference. So I'm also for the removal of -f here. Likely, we should only worry about the creation of the /etc/mtab symlink on first install (ie to support rolling of stage3's or whatever). Alternatively, the symlink should be put in place iff no /etc/mtab exists, by the init/rc-system at boot time, and baselayout not touch it at all. I don't know what's the better option though.
Look at where "make layout" is being called in the baselayout ebuild. This only happens during stage building.
