Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)
On Sun, 18 Aug 2019 at 13:57:58 +0200, Marc Haber wrote:
> On Tue, 13 Aug 2019 18:30:51 +0100, Simon McVittie <smcv@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
Reply to: