Re: [gentoo-dev] Re: rfc: improve file system mounting and unmounting in OpenRC
On Wed, Aug 05, 2015 at 04:50:40AM +, Duncan wrote: > Ian Stakenvicius posted on Tue, 04 Aug 2015 17:17:51 -0400 as excerpted: > > > So what you are suggesting here now is that you want to (A) potentially > > break mounting with the need to externally manage mounts via services in > > openrc instead of just using /etc/fstab, and (B) also break services if > > something doesn't start, which is one of the reasons why you wanted to > > go through with this per-mount service in the first place. My point is > > that no, we should keep localmount as succeeding even if one of the > > dependent services fails to mount, *just like it does right now*, *for > > the same reasons* as it succeeds on failure right now. > > +1 > > IMO, localmount must continue to succeed /by/ /default/, even if some > mounts fail, because it's basically legacy, and must maintain legacy > behavior. Turning it into a wrapper "internally" is fine, but the > overall localmount must still succeed, as too much depends on that > behavior as it is. Here's what I'm trying to deal with. Consider what happens if service a still has "need localmount" and service b has "need mount.foo". Mounting a file system twice causes failures the second time it is mounted, so I either have to add special handling in the new mount script for file systems that are already mounted or come up with a way to make sure localmount runs after all instances of the new mount script. The issue with making sure all mount scripts run before localmount would complicate things more for users because they would have to add the mount.foo symlinks to the appropriate runlevels (boot for local file systems and default for network ones). If I did add special handling to the mount script for an already-mounted file system, what should that be -- to ignore it or remount it? I'm tending toward remount. William signature.asc Description: Digital signature
Re: [gentoo-dev] Re: rfc: improve file system mounting and unmounting in OpenRC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/08/15 10:01 AM, William Hubbs wrote: > On Wed, Aug 05, 2015 at 04:50:40AM +, Duncan wrote: >> Ian Stakenvicius posted on Tue, 04 Aug 2015 17:17:51 -0400 as >> excerpted: >> >>> So what you are suggesting here now is that you want to (A) >>> potentially break mounting with the need to externally manage >>> mounts via services in openrc instead of just using /etc/fstab, >>> and (B) also break services if something doesn't start, which >>> is one of the reasons why you wanted to go through with this >>> per-mount service in the first place. My point is that no, we >>> should keep localmount as succeeding even if one of the >>> dependent services fails to mount, *just like it does right >>> now*, *for the same reasons* as it succeeds on failure right >>> now. >> >> +1 >> >> IMO, localmount must continue to succeed /by/ /default/, even if >> some mounts fail, because it's basically legacy, and must >> maintain legacy behavior. Turning it into a wrapper "internally" >> is fine, but the overall localmount must still succeed, as too >> much depends on that behavior as it is. > > Here's what I'm trying to deal with. Consider what happens if > service a still has "need localmount" and service b has "need > mount.foo". > > Mounting a file system twice causes failures the second time it is > mounted, so I either have to add special handling in the new > mount script for file systems that are already mounted or come up > with a way to make sure localmount runs after all instances of the > new mount script. Yes. I sincerely hope this was always part of the plan??? If localmount is kept as a 'mount -a' then it won't remount anything that's already been mounted, so nothing to worry about there. If it's a wrapper to the individual local mount.*'s then it just has to depend() on them all via a need/want (so that they will be brought in even if they aren't in the runlevel) and/or the mount.*'s need a 'before localmount' so that they're definitely started/attempted first. Am I missing something that makes this harder than it seems? > > The issue with making sure all mount scripts run before localmount > would complicate things more for users because they would have to > add the mount.foo symlinks to the appropriate runlevels (boot for > local file systems and default for network ones). Likely true as things stand now, which is why I expect major changes would be needed in openrc internals to make it so this is not necessary. At minimum, "want" dependencies would need to be used so that if mount.foo's don't exist they won't cause depend() failures. (You thought this system was going to let you get away with -not- using 'want' for mounting, didn't you? :) Of course this still doesn't handle how depend() sections will be dynamically generated from /etc/fstab in the first place, nor how the cache will be affected by this; so there's still lots of work to do to sort that out. > > If I did add special handling to the mount script for an > already-mounted file system, what should that be -- to ignore it or > remount it? I'm tending toward remount. Well you're already deciding to return success if the mount.foo doesn't actually point to a real mount, so I don't see why this can't be extended to return success if the filesystem is already mounted too. But either way, so long as it works. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlXCGyUACgkQAJxUfCtlWe1VngD+P8nVY6FUbYmzcQvRIP7GUi+h Q6V2C+q1yq3Hr1AcqhQBAKGvn790n+XmMiYAbprRFqT4cmWRobEFnhlnPnnQQyuI =jhE8 -END PGP SIGNATURE-
Re: [gentoo-dev] Re: rfc: improve file system mounting and unmounting in OpenRC
On Wed, Aug 05, 2015 at 10:18:13AM -0400, Ian Stakenvicius wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 05/08/15 10:01 AM, William Hubbs wrote: > > On Wed, Aug 05, 2015 at 04:50:40AM +, Duncan wrote: > >> Ian Stakenvicius posted on Tue, 04 Aug 2015 17:17:51 -0400 as > >> excerpted: > >> > >>> So what you are suggesting here now is that you want to (A) > >>> potentially break mounting with the need to externally manage > >>> mounts via services in openrc instead of just using /etc/fstab, > >>> and (B) also break services if something doesn't start, which > >>> is one of the reasons why you wanted to go through with this > >>> per-mount service in the first place. My point is that no, we > >>> should keep localmount as succeeding even if one of the > >>> dependent services fails to mount, *just like it does right > >>> now*, *for the same reasons* as it succeeds on failure right > >>> now. > >> > >> +1 > >> > >> IMO, localmount must continue to succeed /by/ /default/, even if > >> some mounts fail, because it's basically legacy, and must > >> maintain legacy behavior. Turning it into a wrapper "internally" > >> is fine, but the overall localmount must still succeed, as too > >> much depends on that behavior as it is. > > > > Here's what I'm trying to deal with. Consider what happens if > > service a still has "need localmount" and service b has "need > > mount.foo". > > > > Mounting a file system twice causes failures the second time it is > > mounted, so I either have to add special handling in the new > > mount script for file systems that are already mounted or come up > > with a way to make sure localmount runs after all instances of the > > new mount script. > > Yes. I sincerely hope this was always part of the plan??? > > If localmount is kept as a 'mount -a' then it won't remount anything > that's already been mounted, so nothing to worry about there. If it's > a wrapper to the individual local mount.*'s then it just has to > depend() on them all via a need/want (so that they will be brought in > even if they aren't in the runlevel) and/or the mount.*'s need a > 'before localmount' so that they're definitely started/attempted > first. Am I missing something that makes this harder than it seems? 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. > > > > > > The issue with making sure all mount scripts run before localmount > > would complicate things more for users because they would have to > > add the mount.foo symlinks to the appropriate runlevels (boot for > > local file systems and default for network ones). > > Likely true as things stand now, which is why I expect major changes > would be needed in openrc internals to make it so this is not > necessary. At minimum, "want" dependencies would need to be used so > that if mount.foo's don't exist they won't cause depend() failures. > > (You thought this system was going to let you get away with -not- > using 'want' for mounting, didn't you? :) Not exactly, I just don't want to use want along with fstab scanning in netmount to try to make netmount start network file system daemons. I never was opposed to the want dependency on its own. > Of course this still doesn't handle how depend() sections will be > dynamically generated from /etc/fstab in the first place, nor how the > cache will be affected by this; so there's still lots of work to do to > sort that out. There is no plan to dynamically generate depend() functions. William signature.asc Description: Digital signature
Re: [gentoo-dev] new eclass: golang-vcs-snapshot.eclass for golang vcs snapshots
On Tue, Aug 04, 2015 at 02:19:52PM -0500, William Hubbs wrote:
> On Tue, Aug 04, 2015 at 12:17:50PM -0400, Mike Gilbert wrote:
> > The documentation says you are extracting to ${S}, but the function
> > actually extracts to ${WORKDIR}/${PN}.
>
> s/PN/P/
> > I would get rid of the useless "destdir" variable and replace all
> > usages with "${S}". Or update the docs.
>
> I got rid of the f and destdir variables and cleaned up the docs; here
> is the latest; let me know what you think.
>
> William
>
This version is now in the tree.
William
signature.asc
Description: Digital signature
Re: [gentoo-dev] useflag policies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/08/15 02:38 AM, Ben de Groot wrote: > On 4 August 2015 at 22:56, Ian Stakenvicius > wrote: >> Are there any cases where things actually break if a package has >> both flags enabled? IE, is three a package with IUSE="qt4 qt5" >> that when both flags are enabled would build for qt5 only, and >> happens to be a dependency atom of something else that needs it >> to have qt4 support? That to me is the only case where a >> REQUIRED_USE needs to be set on a package. > > I'm not aware we have such a package, but I may be overlooking > something. Either way, I think it is a dangerous road to go down > that way. > I'm not aware of any either, although I haven't done a comprehensive audit of the tree to find out. I would find it unlikely that any such package exists. The thing is, we're already travelling that road (have been for a long while), and IMO there is very little "cost" to travelling this road compared to the so-called "proper" solution of forcing off one flag or the other, ESPECIALLY when we are likely to have both flags default-on soon in the generic desktop profile as was posted earlier. If we do go the REQUIRED_USE="^^" route on packages, then I think it would be best that we change the 'desktop' and other profiles s.t. maintainers need to add their package with whichever flag should be enabled (qt4 or qt5) to package.use, rather than having the qt* flag(s) globally enabled in the profile -- otherwise we end up with end-users having to deal with it. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlXCfk4ACgkQAJxUfCtlWe1CswEA0e4c/gRSbjg0b858+uVFc+z2 +05WUPjFsPpfXrdPs3wA/2r0PyitPRoZAWPWBKm8LhMAC5YIHtjhWA7kh2LTImAQ =gyeU -END PGP SIGNATURE-
Re: [gentoo-dev] rfc: improve file system mounting and unmounting in OpenRC
> "WH" == William Hubbs writes:
WH> The other change I want to make, considering that the mount.* scripts
WH> will actually do the work of mounting the file systems, is to turn
WH> localmount and netmount into wrappers which will do nothing other than
WH> pull in the appropriate mounts. The sys admin would have to configure
WH> which mounts are local vs network using settings in
WH> /etc/conf.d/{local,net}mount.
WH> What do folks think of these changes?
For local filesystems, mount -a is exactly right and should remain. At
least for those of us who prefer only ever halving to edit fstab(5).
Remote filesystems might be differnt, but for local filesystems the
status quo is better.
-JimC
--
James Cloos OpenPGP: 0x997A9F17ED7DAEA6
Re: [gentoo-dev] rfc: improve file system mounting and unmounting in OpenRC
On Wed, Aug 5, 2015 at 8:09 PM, James Cloos wrote: >> "WH" == William Hubbs writes: > WH> What do folks think of these changes? > > For local filesystems, mount -a is exactly right and should remain. At > least for those of us who prefer only ever halving to edit fstab(5). > -- > James Cloos OpenPGP: 0x997A9F17ED7DAEA6 +1 Having yet another place to have to edit to mount local disks is just not a viable option. -- G.Wolfe Woodbury redwo...@gmail.com
[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
