Salt's gitfs backend [1] depends on git-python. Make it easier for Git-lovers to get gitfs support out of the box by adding the `git` USE flag to salt and using it to trigger an RDEPEND on git-python. [1]: http://docs.saltstack.com/ref/file_server/all/salt.fileserver.gitfs.html Reproducible: Always Steps to Reproduce: # emerge -av app-admin/salt # /etc/init.d/salt-minion start $ git clone git://github.com/saltstack/salt-states.git $ cd salt-states # salt-call --local state.highstate test=True Actual Results: [INFO ] Configuration file path: /etc/salt/minion [WARNING ] The function 'grains()' defined in '/usr/lib64/python2.7/site-packages/salt/loader.py' is not yet using the new 'default_path' argument to `salt.config.load_config()`. As such, the 'SALT_MINION_CONFIG' environment variable will be ignored [ERROR ] Git fileserver backend is enabled in configuration but could not be loaded, is git-python installed? [INFO ] Executing command 'ps -efH' in directory '/root' [WARNING ] The function 'grains()' defined in '/usr/lib64/python2.7/site-packages/salt/loader.py' is not yet using the new 'default_path' argument to `salt.config.load_config()`. As such, the 'SALT_MINION_CONFIG' environment variable will be ignored [ERROR ] Git fileserver backend is enabled in configuration but could not be loaded, is git-python installed? [INFO ] Loading fresh modules for state activity local: ---------- State: - no Name: states Function: None Result: False Comment: No Top file or external nodes data matches found Changes: Expected Results: [INFO ] Configuration file path: /etc/salt/minion [WARNING ] The function 'grains()' defined in '/usr/lib64/python2.7/site-packages/salt/loader.py' is not yet using the new 'default_path' argument to `salt.config.load_config()`. As such, the 'SALT_MINION_CONFIG' environment variable will be ignored [INFO ] Executing command 'ps -efH' in directory '/root' [WARNING ] The function 'grains()' defined in '/usr/lib64/python2.7/site-packages/salt/loader.py' is not yet using the new 'default_path' argument to `salt.config.load_config()`. As such, the 'SALT_MINION_CONFIG' environment variable will be ignored [INFO ] Loading fresh modules for state activity local: ---------- State: - no Name: states Function: None Result: False Comment: No Top file or external nodes data matches found Changes: Patch attached. You'll have to fill in #XXXX once a bug ID is assigned ;).
Created attachment 359154 [details, diff] patch adding `git` USE flag and git-python RDEPEND
According to the USE flag policy in: http://devmanual.gentoo.org/general-concepts/use-flags/index.html "The usage of a USE flag should not control runtime dependencies when the package does not link to it. Doing so will create extra configuration for the package and re-compilation for no underlying file change on disk. This should be avoided and instead can be conveyed to the user via post install messages if needed." Since this does not create any on-disk changes, there should not be a USE flag. We could add a postinstall message if you like.
(In reply to Patrick McLean from comment #2) > According to the USE flag policy in: > http://devmanual.gentoo.org/general-concepts/use-flags/index.html > > "The usage of a USE flag should not control runtime dependencies when the > package does not link to it. Doing so will create extra configuration for > the package and re-compilation for no underlying file change on disk. This > should be avoided and instead can be conveyed to the user via post install > messages if needed." Thanks for the quote, that makes sense. As a counter example, www-apps/ikiwiki has 'extras' and 'minimal' USE flags that control the installation of optional RDEPEND entries (and I'd be very surprised if it's the only such package), so I don't think it's quite that cut and dried. Still, salt should be a high-enough level package that folks won't be too annoyed by manually installing optional runtime dependencies. > Since this does not create any on-disk changes, there should not be a USE > flag. We could add a postinstall message if you like. Works for me.
*** Bug 510216 has been marked as a duplicate of this bug. ***
