-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 07/30/2015 09:55 AM, Alon Bar-Lev wrote:
> On 30 July 2015 at 19:15, Ian Stakenvicius <a...@gentoo.org> wrote:
>>
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>
>> On 30/07/15 01:55 AM, Duncan wrote:
>>> Patrick McLean posted on Wed, 29 Jul 2015 15:35:02 -0700 as
>>> excerpted:
>>>
>>>> On Thu, 30 Jul 2015 01:11:30 +0300 Alon Bar-Lev
>>>> <alo...@gentoo.org> wrote:
>>>>
>>>>> On 29 July 2015 at 23:20, William Hubbs
>>>>> <willi...@gentoo.org> wrote:
>>>>>>
>>>>>> so that there is a better idea out there of what I'm
>>>>>> talking about, the OpenRC github repository now has a
>>>>>> mount-service branch.
>>>>>
>>>>> But I still trying to figure out why do we need to keep
>>>>> fstab around. It is pure legacy.
>>>>>
>>>>>
>>>> On what planet is fstab pure legacy? Many utilities use it
>>>> and expect it to exist. For example the ability to do "mount
>>>> /foo" requires a properly configured fstab file (also mount
>>>> -a).
>>>>
>>
>> I think there are two meanings of the word legacy here.
>>
>> #1, /etc/fstab on linux is not legacy, and I don't think anyone
>> here (except possibly for WilliamH as I can't actually tell from
>> his statements) has been calling it 'legacy' in this context.
>
> /etc/fstab is legacy in the sense it did not evolve since early
> days of UNIX. Imagine /etc/crontab was left the same single file,
> but it at least evolved to usr /etc/cron.*/ to ease management of
> multiple sources and ease packaging/maintenance without need to
> parse and rewrite single file when provisioning.
>
> Nobody ignores /etc/fstab existence, I provided solutions of how
> /etc/fstab can be read in flexible method as netifrc does (which
> was actually the core idea of this move), doing so will make the
> service much simpler as it can use external helper scripts to
> provide the data out of whatever source, please re-read my
> message.
>
> However, having the option *NOT* to use /etc/fstab has many
> advantages in security (storing credentials in own files),
> provisioning (no need to race parse/rewrite), dynamic (define the
> location of nfs server based on logic) and many more.
>
> I do not understand why people are so sensitive for a change that
> does not effect the outcome of their need, all that I recommended
> to add is driver:
>
> mount_driver_\${NAME}=fstab mount_mountpoint_\${NAME}=/mnt/auto
>
> driver will be executed by the service, in this case:
>
> openrc-mount-helper-${openrc_mount_driver_\${NAME}}
> ${mount_mountpoint_\${NAME}}
>
> the output will be evaluated. This simple solution will enable the
> service to be generic and provide flexible pure configuration
> (whatever we choose), while support any source of information that
> is capable of constructing this configuration.
>
> Loose nothing gain some, simpler service and constraint fstab
> within driver.
>
> Another drive I can think of is UPnP.
>
> Regards, Alon
>
I'm having a hard time understanding why we need daemons to handle our
filesystems. Can you give me a use case that /etc/fstab is
insufficient for solving?
- --
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJVvxa+AAoJEAEkDpRQOeFwGWUQAKCnuRLHYmUikYu+u0+1Tkck
eFmzW7C/G+Tbm5vqkRwk0F781gIPbpV36QOdIoTfBB65HJ9155VnsISXmQskf1+7
HN2guLTBrtOttZXOyF4KU7klGwElYTmD6tjMmH7aTxy6ID3lMKNtWDlktNgxPcH8
lfYsmB2DJ3+pxdMpPLCg0tGcR+s2RjNKJUnbXNGXO3vzO7PH/gPG9KkqtlVI/78I
Xf1m1e/MCEpRU8c2GCRzDuUkznUp3OMoXysMo3a/1c7NYx+KZ9CIlFZXiOX8CKJ5
hVf1xE0g8spRnH5Bq/EXO0mMhdWLB82ax4mD+jXdMR7H1i8SHjHGqQwQlKRFGIyg
UFfFcgz1GswGGar/AjkKz02FuiMYgJ7kU2nRHBlNsfjnjsdc8iIxPGhcCMWYZjuD
kLE/c6487ymQTMMYlIZ/qG7/90k57/TXZq0AuBPCB4/HD2vHMJBcYQkoWlnQSGEC
oYrVEvb9N1eKYe7/IpxnKVGKTZY1OP+xtDGvpPwp1MtE0GZ9VQbhS1+aJy6nVrs1
Uxx6/H7RTFwD5Af4V6mNe20ucz5mkEJxX9qTsNMrDAu+DHFUC3CTtYmeRN9Fsbve
ibHsIh1N0mI0bOvN16VK2s/ToahnsP09WvkJpnMIyJSfs4qWfpOhTWN8JEMWEdo2
j7V+HGJZ2GNYm3K0hFJI
=YuTA
-----END PGP SIGNATURE-----
