retitle 821793 fusermount should not attempt to use /etc/mtab severity 821793 normal reassign 821793 fuse thanks bye exit whatever
On Apr 19 2016, Santiago Vila <sanv...@unex.es> wrote: > On Tue, Apr 19, 2016 at 09:42:11AM -0700, Nikolaus Rath wrote: >> Your build system is missing /etc/mtab (should be a symlink to >> /proc/mounts). >> >> At the moment I consider this a bug in your system, not in the >> package. But I'm willing to be convinced by suitably convincing >> references :-). > > Ok. Let's try: > > * I think we can both agree that a package should be buildable both > in "native" form but also in a chroot. > > * The file does not belong to any package: > > $ dpkg -S /etc/mtab > dpkg-query: no path found matching pattern /etc/mtab > > * chroots are usually created by debootstrap. debootstrap does not > create the symlink either. > > * schroot does not create the file when entering a chroot. > > * sbuild does not create the file when building a package. > > Based on the above, it seems that the file is only useful/required in > living running systems at most, but not on chroots used to build > packages. That's convincing. But the problem is that /etc/mtab is not used by the python-llfuse build directly, but by the "fusermount" command (which is called by the unit tests). fusermount is shipped by the fuse package, and presumably has a better case for opening /etc/mtab. > I found this documentation from Linux From Scratch: > > http://www.linuxfromscratch.org/lfs/view/development/chapter06/createfiles.html > > Historically, Linux maintains a list of the mounted file systems in > the file /etc/mtab. Modern kernels maintain this list internally and > exposes it to the user via the /proc filesystem. To satisfy utilities > that expect the presence of /etc/mtab, create the following symbolic > link: > > ln -sv /proc/self/mounts /etc/mtab > > The way I read that, it seems mtab is a leftover from the past and > it's there only for "historical reasons", but it does not seem to be > something which is actually required. > > Moreover, accesing mtab directly seems very "low level". The "mount" > command shows the mounted filesystems (even if in a different format). > > But even this seems to be deprecated as well, this is what the mount > manpage says about mount's "listing mode": > > The listing mode is maintained for backward compatibility only. > > For more robust and customizable output use findmnt(8), especially > in your scripts. > > The findmnt command belongs to the mount package, which is "Essential: yes". > > So, to summarize: In a Debian chroot used to build packages, the symlink > /etc/mtab may or may not be there (as this report itself shows). > > OTOH, in a Debian system the findmnt command is always there. > > Therefore, packages should probably not rely on /etc/mtab. > > If you still do not agree, please downgrade this bug, clone it, and > reassign the cloned bug to sbuild, etc. I don't want to dodge the issue, but I think reassigning to "fuse" is really the only thing I can do. Unless you would argue that the python-llfuse build should not be calling fusermount, because it's intended for use on living systems only...? Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
