Re: Value in adding Shepherd requirements to file-systems entries?

[Richard Sent]

Hi Felix,

> Someone once gave me this service [1] to mount a file-system declared
> with (mount? #f). [2] It's been working ever since.

Thanks! I know custom services can be made that can work on a
case-by-case basis. I was curious about the value of encapsulating that
logic within an operating-system file-systems field and reusing the
existing code of file-system-shepherd-service in (gnu services base) and
mount-file-system in (gnu build file-system).

My comment on NFS support is more about how mount-file-system supports
mounting NFS file-system records, but the existing code that actually
uses mount-file-system tries mounting all file systems before networking
has begun. Ergo, the fact that mount-file-system supports NFS seems a
bit extraneous at present, at least insofar as I can decipher.

I submitted a patch for what I'm thinking at
https://issues.guix.gnu.org/70542. If this winds up merged I believe
your code could be rewritten to remove [1] and replace [2] with

--8<---------------cut here---------------start------------->8---
(file-system
   (device "wallace-server.local:/acct")
   (mount-point "/acct")
   (type "nfs")
   (requirement '(avahi-daemon)) ;resolve .local
   ;; (flags '(no-atime no-dev no-exec read-only))
   ;; (options "proto=tcp6,timeo=300,nolock")
   (check? #f)
   (mount-may-fail? #t)
   (create-mount-point? #t))
--8<---------------cut here---------------end--------------->8---

(I don't have an NFS system on my LAN to test so no promises)

Hopefully that shows what I'm thinking. If anyone has thoughts I'd love
to hear it, either here or in the patch depending on what's appropriate.

-- 
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.