Some Unix variants name GID 0 "wheel".  Unfortunately, one cannot
specify this group by ID, because Python conflates integer 0 with
boolean False, nor can one specify this group using the string '0',
because of assumptions in the Salt or Python codebases regarding group
names.

The salt-cloud packages automatically pull in the pycrypto and libcloud
dependencies for RedHat and Debian (at least when using the SaltStack
repos), so it doesn't really make sense to install these dependencies
using pip. By default we no longer use pip, but the old behaviour can be
restored by setting 'salt:use_pip' to True in the pillar.

There could probably be a case made for removing the pip stuff
altogether, but we will leave it in for the time being to preserve some
backwards compatibility.

As mentioned in issue #118, provider files may contain passwords
or API keys and should be restricted. Profiles/maps are probably
OK with the defaults.

This obsoletes the salt:cloud:folders and salt:cloud:providers pillar
entries. Provider keys have been moved to /etc/salt/pki/cloud.

Please refer to issue https://github.com/saltstack-formulas/salt-formula/issues/113.

If you are installing Salt via git/pip, the formula will try to overwrite your
install with packaged versions. This setting makes it possible to avoid that.

Using a variable named salt is a bad idea when salt already has a variable
named salt.

Update sls files to match name change in map.jinja.

Added map.jinja solution more in line with other formulas,
This also improves issue #30

and pull request #30

Fixing typo

Removing crypto pip dependency for the ``os_family`` ``Debian``.

Refer to PR:
https://github.com/saltstack-formulas/salt-formula/pull/60#issuecomment-62029457

Fixes:
https://github.com/saltstack-formulas/salt-formula/issues/59

Refer to PR:
https://github.com/saltstack-formulas/salt-formula/pull/60

It doesn't seem to be available from pip anymore, and may not be
a real dependency. Salt-cloud certainly seems to work fine without
it.