Subject: bug#60246: Inability to add pseudo-filesystem fstab entries

From: Tobias Geerinckx-Rice <[email-masked]>
Date: Wed, 21 Dec 2022 23:50:08 +0100

Hi Bruno,

mirai 写道：
> Does not result in a fstab entry line, which makes it impossible 
> to mount. According to Guix docs, this shouldn't be the case:

Hm, yes, strictly speaking that is so.

It feels a bit weird to add or omit fstab entries based on MOUNT? 
being true or false, but… it seems like a good proxy for what the 
user *means* in both cases?

If the following is really true, we have little other choice:

> ;; In particular, things like GIO (part of GLib) use it to 
> determine the set
> ;; of mounts, which is then used by graphical file managers and 
> desktop
> ;; environments to display "volume" icons.  Thus, we really need 
> to exclude
> ;; those pseudo file systems from the list.

so I wouldn't be opposed to it.

>                         %pseudo-file-system-types)

I disagree that overlayfs is a ‘pseudo-file-system’, any more than 
NFS would be.  It should not be in that list to begin with.

And this is where it gets fun: apparently… it was added at my 
request‽ :-)

Or at least Ludo's interpretation of that requests, in commit 
df1eaffc3:

    file-systems: Expound '%pseudo-file-system-types'.
    
    Reported by Tobias Geerinckx-Rice <[email-masked]>.
    
    * gnu/system/file-systems.scm (%pseudo-file-system-types): Add
    "debugfs", "efivarfs", "hugetlbfs", "overlay", and 
    "securityfs".

Even in this list, ‘overlayfs’ has huge 
one-of-these-is-not-like-the-others energy, so I wonder what the 
reason was.  I don't remember.

I'd happily revert it if I didn't suspect that it was to work 
around some real (installer?) bug…

Kind regards,

T G-R