On Sun, 18 Aug 2019 at 13:57:58 +0200, Marc Haber wrote: > On Tue, 13 Aug 2019 18:30:51 +0100, Simon McVittie <s...@debian.org> > >bubblewrap and other container-runners often use this when setting > >up containers - for example if you have a Flatpak app installed, try > >something like > > > > flatpak run --command=mount org.gnome.Recipes > > > >and you'll see that the container's /etc is a mixture of read-only > >bind-mounts from the host system and read-only bind-mounts from the > >runtime, some of which are individual files. > > That must be a horrible clutter in mtab though.
There are a lot of lines in /proc/$pid/mounts for $pid inside the container, yes. However, bubblewrap and other unprivileged container-runners do not (cannot!) alter the mount table outside the container (they operate in a private mount namespace owned by a private user namespace), so /proc/$pid/mounts for $pid outside the container remains uncluttered. /etc/mtab is recommended to be a symlink to /proc/self/mounts, so it reflects the mount table that is active for the process reading it. In older installations where it was still a regular file, it was updated by mount(8), so in practice it will reflect the mount table that is active for the "init namespace" (the namespaces to which pid 1 belongs). bubblewrap uses mount(2) directly, not mount(8), so it will not alter /etc/mtab if that is a regular file. In any case, I think avoiding "clutter" in the mount table is quite a long way down the list of the most important properties of a system. I would prefer Flatpak to bind-mount in the correct mixture of the runtime's /etc and the host system's /etc to make the app work correctly, however much clutter that might result in. If this clutter offends you, one good way to reduce it is to encourage packages to work correctly with fewer "boilerplate" files in /etc (the same category of changes that results in non-sysadmin-modified D-Bus policy fragments migrating from /etc/dbus-1/system.d to /usr/share/dbus-1/system.d, for example). > We should also have a document containing what we want to have in the > future, such as a comprehensive roadmap. Sorry, I do not have enough Debian time available to write down a comprehensive road map for the teams and packages I'm involved with, never mind the whole project. Any time I spend on writing a road map advocating good ideas is time that I am not spending on implementing those good ideas. For goals confined to a group of closely cooperating packages and maintainers, the way to achieve changes is to just make them. For goals with a wider scope, I think the closest tool we have is release goals. If you want to propose release goals around new technologies in Debian, please do! Debian is mostly a do-ocracy - the people who do the work decide what the work will be - so I don't think anyone really has the authority to write down a road map for the project as a whole and expect developers to follow it. The DPL, release team and technical committee are probably the closest to the positions that could meaningfully define a road map, but even those cannot assign or require developers to work on its contents. smcv