Re: [gentoo-dev] rfc: improve file system mounting and unmounting in OpenRC
All, This is my previous post, added on the right thread this time. as I have always said, my views can evolve with civil discussion, and there has been some good feedback on this. I also got a suggestion for handling network file systems that would mean we wouldn't have to keep track of the specific clients needed to mount network file systems; we could let the distros tell us what the network file system types are and which services should be started to support them. Look at the new-netmount branch for that. Basically it would be a series of files in a directory which would have the name of a filesystem type as their file name, then inside each file, the name of the service that supports them. The point of debate I suppose is the dependency type that should be used for these. On the branch it is use, which requires you to add the appropriate service to the runlevel netmount is in, but some want it to be want once it is implemented. Also, I want to talk more about netmount and localmount failing. If netmount and localmount are set up to fail if one of the file systems they mount fails (which is what other init systems out there do), the sys admin can control whether the mount -a command cares about the status of specific file systems by adding nofail to the mount options in fstab. By default it would care, but if you add nofail to the mount options, you would affectively tell mount -a to not be concerned about whether the mount succeeds or not. Thoughts? William signature.asc Description: Digital signature
[gentoo-dev] Re: rfc: improve file system mounting and unmounting in OpenRC
William Hubbs posted on Thu, 06 Aug 2015 16:36:49 -0500 as excerpted: Also, I want to talk more about netmount and localmount failing. If netmount and localmount are set up to fail if one of the file systems they mount fails (which is what other init systems out there do), the sys admin can control whether the mount -a command cares about the status of specific file systems by adding nofail to the mount options in fstab. By default it would care, but if you add nofail to the mount options, you would affectively tell mount -a to not be concerned about whether the mount succeeds or not. [As my previous replies were concerned with this and suggested more complicated solutions...] I like it. =:^) The nofail option is mount/fstab native, so it's the proper way(tm) and already documented at their level. The one catch is that since it's a change from current localmount/netmount behavior, the upgrade guide should point it out, and a news item pointing it out is effectively mandatory. In the upgrade guide (presumably on the wiki), I'd make it warning level, making it stand out. Similarly, in the news item, I'd consider making it a separate paragraph, introduced with *** WARNING *** or similar. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] cmake-utils.eclass: two improvements
Folks, disregard my previous msg on this thread, it was supposed to go somewhere else. William signature.asc Description: Digital signature
Re: [gentoo-dev] cmake-utils.eclass: two improvements
All, as I have always said, my views can evolve with civil discussion, and there has been some good feedback on this. I also got a suggestion for handling network file systems that would mean we wouldn't have to keep track of the specific clients needed to mount network file systems; we could let the distros tell us what the network file system types are and which services should be started to support them. Look at the new-netmount branch for that. Basically it would be a series of files in a directory which would have the name of a filesystem type as their file name, then inside each file, the name of the service that supports them. The point of debate I suppose is the dependency type that should be used for these. On the branch it is use, which requires you to add the appropriate service to the runlevel netmount is in, but some want it to be want once it is implemented. Also, I want to talk more about netmount and localmount failing. If netmount and localmount are set up to fail if one of the file systems they mount fails (which is what other init systems out there do), the sys admin can control whether the mount -a command cares about the status of specific file systems by adding nofail to the mount options in fstab. By default it would care, but if you add nofail to the mount options, you would affectively tell mount -a to not be concerned about whether the mount succeeds or not. Thoughts? William signature.asc Description: Digital signature
Re: [gentoo-dev] emerge --binpkg-changed-deps
* Zac Medico schrieb am 05.08.15 um 00:04 Uhr: On 08/04/2015 01:16 PM, Marc Schiffbauer wrote: hi all, i find it a bit hard to understand how --binpkg-changed-deps is supposed to work and what implications it has. Moreover I think the man page is not very clear about what it does: --binpkg-changed-deps [ y | n ] Tells emerge to ignore binary packages for which thecorresponding ebuild dependencies have changed since thepackages were built. In order to help avoid issues withresolving inconsistent dependencies, this option is automatically enabled unless the --usepkgonly option is enabled. Behavior with respect to changed build-time dependencies iscontrolled by the --with-bdeps option. This looks a bit confusing to me. Am I alone with that? If I understand that option right, maybe this text is better? --binpkg-changed-deps [ y | n ] When enabled tells emerge to ignore a binary package and do a source build instead if the corresponding ebuild runtimedependencies (RDEPEND) have changed in the portage tree sincethe package was built. It doesn't necessarily imply a source build, since you can have multiple binary packages available. I see. So this might be better: When enabled tells emerge to ignore a binary package if the corresponding ebuild runtime dependencies (RDEPEND) have changed in the portage tree since the package was built. With FEATURES=binpkg-multi-instance, you can have multiple local binary packages of the same package version in PKGDIR. Even without FEATURES=binpkg-multi-instance, you can also have multiple binary packages of the same package version coming from multiple binhosts. I had hoped for a feature like that and did not realize its already there, great! But thats another story.. To help avoid issues with resolving inconsistent dependenciesthis option is enabled by default unless using source builds isdisabled by the --usepkgonly option. Adding using source builds is disabled would be a valid way to clarify the meaning of --usepkgonly. Yes, I think this will improve the description. If the --with-bdeps option is also enabled, changed build-time dependencies (DEPEND) will be considered instead. Not instead, but in addition to. If the --with-bdeps option is also enabled, changed build-time dependencies (DEPEND) will also be considered. -Marc -- 0x35A64134 - 8AAC 5F46 83B4 DB70 8317 3723 296C 6CCA 35A6 4134 signature.asc Description: Digital signature
Re: [gentoo-dev] Re: rfc: improve file system mounting and unmounting in OpenRC
On Aug 6, 2015, at 6:22 PM, Duncan 1i5t5.dun...@cox.net wrote: William Hubbs posted on Thu, 06 Aug 2015 16:36:49 -0500 as excerpted: Also, I want to talk more about netmount and localmount failing. If netmount and localmount are set up to fail if one of the file systems they mount fails (which is what other init systems out there do), the sys admin can control whether the mount -a command cares about the status of specific file systems by adding nofail to the mount options in fstab. By default it would care, but if you add nofail to the mount options, you would affectively tell mount -a to not be concerned about whether the mount succeeds or not. [As my previous replies were concerned with this and suggested more complicated solutions...] I like it. =:^) The nofail option is mount/fstab native, so it's the proper way(tm) and already documented at their level. The one catch is that since it's a change from current localmount/netmount behavior, the upgrade guide should point it out, and a news item pointing it out is effectively mandatory. In the upgrade guide (presumably on the wiki), I'd make it warning level, making it stand out. Similarly, in the news item, I'd consider making it a separate paragraph, introduced with *** WARNING *** or similar. Can we get nofail immediately in the mount -a variants of localmount/netmount and expand that in netmount to make the nfsclient dep be a use or a need depending on if it's set or not?? That would imo kill the existing bug that started all of this too. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-dev] Re: rfc: improve file system mounting and unmounting in OpenRC
William Hubbs posted on Wed, 05 Aug 2015 10:26:33 -0500 as excerpted: It isn't localmount that would have the issue, but mount.* because they are lexically after localmount, so you would end up with localmount doing a mount -a then mount.* coming later trying to mount file systems again that were mounted by localmount. But if localmount is a wrapper, then it pulls them in and they're already started (if they'll mount), just like they are now. You'd just have to have it still return success even if one of the wrapped mounts fails, in ordered to maintain compatibility. So coming later won't be a problem, if they're wrapped by localmount, because it will have already started them anyway, so they'll already be detected as started. Meanwhile, if localmount is not made a wrapper but continues to be mount -a, then you will indeed need logic in the individual mounts to see if they're already mounted, but a robust system will need that in any case, because there's simply too many reasons, including manual mounting, that they're already mounted. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: rfc: improve file system mounting and unmounting in OpenRC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/08/15 02:58 AM, Duncan wrote: William Hubbs posted on Wed, 05 Aug 2015 10:26:33 -0500 as excerpted: It isn't localmount that would have the issue, but mount.* because they are lexically after localmount, so you would end up with localmount doing a mount -a then mount.* coming later trying to mount file systems again that were mounted by localmount. But if localmount is a wrapper, then it pulls them in and they're already started (if they'll mount), just like they are now. You'd just have to have it still return success even if one of the wrapped mounts fails, in ordered to maintain compatibility. So coming later won't be a problem, if they're wrapped by localmount, because it will have already started them anyway, so they'll already be detected as started. The problem with this though is that making localmount be a wrapper for a dynamic list of services is likely going to be difficult, because depend() would need to be filled in according to what the mount.* services are that people would want -- so should only the ones in the same runlevel be started, or should all the ones that match an fstab entry be started; and then there's the cache issue due to the fact that detection of the mount.* services will need to occur based on the contents of /etc/init.d/ itself. This is where the new system falls down IMO (as discussed in previous emails) -- it's all fine and good to say openrc can just do X in the locamount service, but openrc doesn't actually have a nice way to do this type of thing yet (afaik) without making changes to internals. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlXDaOoACgkQAJxUfCtlWe1e5gEApmGThElPTFf+cNqBugVHC7KF W0TnM+0lNjzS1/jwN+oBAKSfA+zd4JkZDOS/xfKKeTMqV9+dg0JtOQQWMAuQNsrN =dY4B -END PGP SIGNATURE-
