openbsd_pkg module should use -z to allow installing packages with alternatives

[landryb]

Issue Type:

Bug Report/Feature Request

Ansible Version:

1.6.1, but same in master

Environment:

OpenBSD

Summary:

openbsd_pkg 's module doesnt allow to install a package when it has alternatives - ie for example php-fpm, which could be 5.3 or 5.4 - or python, where 2.6, 2.7 and 3.3 are available

Steps To Reproduce:

playbook snippet:

- name: install php-fpm
  openbsd_pkg: name=php-fpm-5.4 state=installed

Expected Results:

php-fpm 5.4 should have installed

Actual Results:

failed: [twilight.rhaalovely.net] => {"failed": true, "item": ""}
msg: Error from http://ftp.fr.openbsd.org/pub/OpenBSD/5.5/packages/amd64/php-fpm-5.4.tgz
ftp: Error retrieving file: 404 Not Found

pkg_add has this feature that if you use -z, it will try fuzzy-matching the package name/version, if you provided it enough details

Various usescases for -z ..

$ sudo pkg_add -I php-fpm-5.4*  
Error from http://ftp.fr.openbsd.org/pub/OpenBSD/5.5/packages/amd64/php-fpm-5.4*.tgz
ftp: Error retrieving file: 404 Not Found
$ sudo pkg_add -Iz php-fpm      
Ambiguous: php-fpm could be php-fpm-5.3.28p3 php-fpm-5.4.24
$ sudo pkg_add -Iz php-fpm-5.4*
php-fpm-5.4.24: ok

If openbsd_pkg would add -z in pkg_add invocation in https://github.com/ansible/ansible/blob/devel/library/packaging/openbsd_pkg#L127, then i would be able to install the correct version of the package within the alternatives, specifying php-fpm-5.4* in the name arg.

[eest]

Thank you for the report. I don't speak for the ansible team, but since I feel personally responsible for the module in question I wish to discuss a few things.

I just installed a fresh -current i386 test machine to verify the -z behaviour. I noticed I was not able to install the package like the example above shows:

# pkg_add -Iz php-fpm-5.4*
quirks-2.11 signed on 2014-09-09T12:20:01Z
Ambiguous: php-fpm-5.4* could be php-fpm-5.4.32 php-fpm-5.3.28p9 php-fpm-5.5.16
#

I would also expect that any package name installable via the module should be removable via the module. One problem here is that pkg_delete does not support a -z flag and does not seem to handle it naturally:

# pkg_info | grep php
php-5.4.32          server-side HTML-embedded scripting language
php-fpm-5.4.32      stand-alone FPM version of PHP
# pkg_delete -I php-fpm-5.4* 
Problem finding php-fpm-5.4*
# 

What are your ideas regarding this? Have the module try to find a best match based on what is installed?

Lastly, I am not aware how much testing has been performed on the port, but I would not add such a flag lightly given that pkg_add already behaves differently with return values and such depending on if the package name contains a version number or not, and the module tries to handle this. I am not sure how -z changes the rules.

At least in -current the return value changes its behaviour, meaning we probably need to change some assumptions the module currently makes as well:

# pkg_add -I php-fpm-5.5
quirks-2.11 signed on 2014-09-09T12:20:01Z
Error from http://ftp.eu.openbsd.org/pub/OpenBSD/snapshots/packages/i386/php-fpm-5.5.tgz
ftp: Error retrieving file: 404 Not Found
Can't find php-fpm-5.5
--- php-fpm-5.5 -------------------
Can't install php-fpm-5.5: not found
# echo $?                
1
# pkg_add -Iz php-fpm-5.5
quirks-2.11 signed on 2014-09-09T12:20:01Z
Ambiguous: php-fpm-5.5 could be php-fpm-5.3.28p9 php-fpm-5.4.32 php-fpm-5.5.16
# echo $?                 
0

[jimi-c]

For linking purposes, there is an associated PR: #8991

[landryb]

Yeah, the server i wrote & tested the patch on was running 5.5 - i have to admit i didnt had time to test -current. I think pkg_add -z behaviour changed..

As for pkg_delete, it doesnt need to support a -z flag for the php-fpm case since all alternatives conflict, but thatd be a problem for say python where multiple versions can coexist.

[mpdehaan]

Hi!

Thanks very much for your interest in Ansible. It sincerely means a lot to us.

On September 26, 2014, due to enormous levels of contribution to the project Ansible decided to reorganize module repos, making it easier
for developers to work on the project and for us to more easily manage new contributions and tickets.

We split modules from the main project off into two repos, http://github.com/ansible/ansible-modules-core and http://github.com/ansible/ansible-modules-extras

If you would still like this ticket attended to, we will need your help in having it reopened in one of the two new repos, and instructions are provided below.

We apologize that we are not able to make this transition happen seamlessly, though this is a one-time change and your help is greatly appreciated --
this will greatly improve velocity going forward.

Both sets of modules will ship with Ansible, though they'll receive slightly different ticket handling.

To locate where a module lives between 'core' and 'extras'

• Find the module at http://docs.ansible.com/list_of_all_modules.html
• Open the documentation page for that module
• If the bottom of the docs say "This is an extras module", submit your ticket to https://github.com/ansible/ansible-modules-extras
• Otherwise, submit your pull request to update the existing module to https://github.com/ansible/ansible-modules-core
• action_plugins (modules with server side components) still live in the main repo. If your ticket affects both, open the ticket
  on the module repo just the same.

Additionally, should you need more help with this, you can ask questions on:

• the ansible-project mailing list: https://groups.google.com/forum/#!forum/ansible-project

Thank you very much!