-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 07/27/2015 03:26 PM, William Hubbs wrote: > All, > > I have been looking over this bug for some time attempting to find > a good solution [1]. > > The original proposal is to add a "want" dependency which would > work like "need" but would not fail if the services wanted did not > start [2]. > > I agree that the "want" dependency is a valid feature request. > However, I believe there is a better way to handle the issue in the > original bug. Basically, I want to follow the suggestion in this > bug instead [3]. > > My concern about the original proposal is that it will make > netmount try to start all daemons that handle file systems, whether > or not they are actually necessary. > > The proposal in [3], on the other hand, is to create a mount script > that works like netifrc. It would mount a single file system, which > would be determined by the link it was called from, much like how > netifrc determines which interface to work on. > > Some of the advantages of this approach are listed in the bug. Here > are a few more I can think of. > > - it will eliminate some of our incompatibilities with busybox [4] > [5]. > > - It will give us honest reports of success or failure with regard > to mounting file systems (netmount and localmount can't do that). > > - Currently, we have to skip over certain file systems that we > can't unmount during shutdown. With the new approach, if the mount > script mounts a file system during boot, it will be able to unmount > the same filesystem during shutdown, so that will eliminate more > complexity in our mount/unmount handling. > > The one down side of the new approach is the migration away from > netmount and localmount. I I will need to keep them as wrappers for > a release or two so we can fix all of our other services that have > dependencies on them. > > I'll also work on making the transition as smooth as possible for > our users. I believe I'll be able to set up the initial symlinks > for the multiplexed mount script based on fstab contents > automatically, but I'm not sure about how much more automation I'll > be able to do. I will automate more as I come across ways to do so, > and I am open to suggestions for how to do so. > > Let me know what you think. > > William > > [1] https://bugs.gentoo.org/show_bug.cgi?id=537996 [2] > https://bugs.gentoo.org/show_bug.cgi?id=406021 [3] > https://bugs.gentoo.org/show_bug.cgi?id=426944 [4] > https://bugs.gentoo.org/show_bug.cgi?id=468600 [5] > https://bugs.gentoo.org/show_bug.cgi?id=468604 > What would a migration be like? For example, I manage filesystems exclusively through fstab (to my knowledge). Would this be useful for, say, mounting over the network? What would managing FSes with openrc look like?
- -- 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 iQIcBAEBCAAGBQJVtugMAAoJEAEkDpRQOeFwBcUQAMb8I39T8ie4S6BWN3+dQ3FC GlzTaTTVn3cghMsjD956T3pwnKVp7Nak4FOEZj19LAciulP+++/me+pIEYMioR5x 3d8237OCgAmSAFk5/ej1wHdQrVR8rOcwgxtqtYLs77RJDwJ1/eMfmlbBzBTpdE8O bmEuVHCJdxvKbp+ZUjka6BTYr7rzpU5w+wUW9SWR3CBW4a1E3JKs9XurGt9JUmTa l1h2Ftw0xZkKXvKt6pJ7obBTrA7fXcuWw/hgvWz4iyofQlsvSmkC+GmIL/nstZMs bBgkTv8idtSNoGZebtM7jxdzIpUnn6j9rZcpo0J5ZQdEDt4xkw6YtfsrMH1mPmI8 2KYzKw/hesVtOtWgyEJvbRbIrrTKA+rKoIxx928dMHVJBqn2/LJa0QUn/oGFaOcX P/5UzzXdDJlbQYKRGH/xU1d5hu/B3DGI6MTgfsGjgr7Bn5+W8PZhO9zcKKJwjxn0 Fl0MD5ibp759ESr07YcjqKOHr0vurc1/Ww9xn9s/gdvcMQxCdzKp/olo3GOxCi66 TjU25hTbUOA6ZuQe/n3zZ+I/ud/uPYbVX6hdT/oNaiCob3PR6zH6/cc8FuVAEryV jqEVrIvnbN+CTi1DTIPAFOPq5PcOvO7NHCLXYqcS3gXH/JEIq0U2+BWdx13s4Whz Run8YkWYZjNl4Fz2a+oA =7yuO -----END PGP SIGNATURE-----
