guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 1/4] gnu: Separate util-linux into three packages.


From: Ludovic Courtès
Subject: Re: [PATCH 1/4] gnu: Separate util-linux into three packages.
Date: Tue, 15 Nov 2016 11:46:01 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

John Darrington <address@hidden> skribis:

> On Mon, Nov 14, 2016 at 10:48:18AM +0100, Ludovic Court??s wrote:
>      John Darrington <address@hidden> skribis:
>
>      >      GuixSD doesn???t use the ???mount??? command to mount file 
> systems so that
>      >      shouldn???t have any influence.
>      >
>      > What does it use instead?
>      
>      The ???mount??? system call; see (gnu build file-systems).
>
> I confess, I have not really thought about this before. But supposing 
> somebody has in their /etc/config.scm:
>
>   (file-systems 
>    (cons*
>     (file-system
>       (device "my-root")
>       (title 'label)
>       (mount-point "/")
>       (type "ext4"))
>     (file-system
>       (device "fileserver.example.com:/home")
>       (title 'device)
>       (mount-point "/home")
>       (type "nfs4"))
>     %base-file-systems))
>
> Would the /home filesystem then get mounted on boot?

Maybe not.  :-)

The man page for mount(2) says:

--8<---------------cut here---------------start------------->8--- Values
for the filesystemtype argument supported by the kernel are listed in
/proc/filesystems (e.g., "btrfs", "ext4", "jfs", "xfs", "vfat", "fuse",
"tmpfs", "cgroup", "proc", "mqueue", "nfs", "cifs", "iso9660").  Further
types may become available when the appropriate modules are loaded.
--8<---------------cut here---------------end--------------->8---

I don’t know what happens with NFS, you’ll have to tell us.

>      > I'm irritated that util-linux has so many, completely unrelated things 
> in it.  For example
>      > it contains the "mount", "cal" and "col" commands.    Regardless of 
> the NFS issues, I 
>      > suggest we consider separating it anyway, into several packages all 
> deriving from the common
>      > source.
>      
>      The strategy is to stick to what upstream does, in general, and I???m not
>      convinced splitting would buy us much (in terms of disk usage, for
>      instance.)
>
> In general I think that is a sensible strategy.  Splitting, would not buy us 
> anything 
> in terms of disk space, but I think it would mean less rebuilding when some 
> configure 
> option needs to be changed.

Yeah, but that’s probably not a significant improvement in terms of
avoiding rebuilds.

Ludo’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]