Gentoo salt-0.11.0 and salt-9999 ebuilds available

[Ryan Schneider]

All,

The 0.11.0 ebuild is up on the gentoo mirrors now.  Also there's now a 9999 ebuild, which at the moment points to 'master' but we'll be switching it to point to 'develop' here shortly (in the next sync pass so within an hour or so).

For those unfamiliar with Gentoo, 9999 ebuilds are the convention to allow one to install the latest 'trunk' for a package:

  sudo emerge =salt-9999

There's also some additional config settings required to prevent this from being done accidentally. ;)

Thanks,

Ryan

[Erik Johnson]

Nice. I am not a Gentoo user, but I did make several recent changes to the ebuild pkg provider to make it work with the new multiple-package feature in 0.11.0. I would appreciate it if you could test package installation and the new multiple-package stuff, as I was unable to do so.

--

-Erik

"For me, it is far better to grasp the universe as it really is than to persist in delusion, however satisfying and reassuring."  -- Carl Sagan

[Thomas S Hatch]

Ryan,

I am wondering if this should point to develop or master, we have (as part of the version and internal git management changes) started to merge master with develop on a regular basis when develop is passing tests and appears to be in a more stable place. So having the 9999 ebuild follow master might make for a more pleasant experience for users

[Sean Channel]

I would agree following master would be better. The daily builds on
Launchpad are only able to import from HEAD, unfortunately.
_S.

[Ryan Schneider]

9999 ebuilds are supposed to be pretty cutting edge.  So for example, right now they should probably point to what will most likely become 0.12.0 rather than 0.11.1, it's that's master then I'll ask for it to change.  It's a one line change, so easy enough to switch.  Except that the maintainer of the ebuild just went on holiday, so it might not get switched until the new year.

@Erik,: I'll check out the feature, thanks.  I'm currently not really using the SLS/Config Management side of Salt, just the remote execution side, but I should be able to whip up a test case and go through the code today.

Thanks,

Ryan

[Erik Johnson]

On Wed, Dec 19, 2012 at 12:28 PM, Ryan Schneider <ryanlees...@gmail.com> wrote:

9999 ebuilds are supposed to be pretty cutting edge.  So for example, right now they should probably point to what will most likely become 0.12.0 rather than 0.11.1, it's that's master then I'll ask for it to change.  It's a one line change, so easy enough to switch.  Except that the maintainer of the ebuild just went on holiday, so it might not get switched until the new year.

@Erik,: I'll check out the feature, thanks.  I'm currently not really using the SLS/Config Management side of Salt, just the remote execution side, but I should be able to whip up a test case and go through the code today.

Thanks,

Ryan

Thanks. The details on how to configure the SLS are in the release notes and the documentation for the pkg state:

http://salt.readthedocs.org/en/latest/topics/releases/0.11.0.html
https://salt.readthedocs.org/en/latest/ref/states/all/salt.states.pkg.html#salt.states.pkg.installed

[Ryan Schneider]

In general it looks good.  I'm not a huge fan of emerge --sync getting run each time highstate is run, because of this line in states.pkg.installed:

if refresh or os.path.isfile(rtag):
        changes = __salt__['pkg.install'](name,
                                          refresh=True,
                                          ...

    

What's the purpose of forcing the refresh flag like that?  

I'm also submitting a minor Pull Request so the import portage line in ebuild.py works in a virtualenv.

Also, while I believe this is correct thing to do, it's worth noting that for Gentoo the pkg names have to be fully qualified with their category name.  So for example "www-servers/apache" instead of just "apache".  IIRC, I don't think the portage Python API supports partial name-only searches, only higher level command tools like qlist or equery seem to support that.

Thanks,

Ryan

[Ryan Schneider]

Sorry, just realized emerge --sync is only run if a package isn't found.  I still think if one sets up their SLS like so:

test_pkgs:

  pkg.installed:

    - pkgs:

      - "virtual/emacs"

      - "net-analyzer/traceroute"

    - refresh : false

(That is, with an explicit refresh=false param) the refresh should be skipped.  I believe that would involve a change like setting the default argument to refresh=None and changing the check to "if refresh or (os.path.isfile(rtag) and refresh is None):".  Since Gentoo is a rolling distro, emerge --sync causes a lot more churn than the equivalent in other distros.

Thanks,

Ryan