Hey there, any news on this? I'm looking into aura <https://github.com/aurapm/aura> right now. It would be good if an Ansible module was created (In the meantime, I will try command: aura...)
On Wednesday, 16 July 2014 02:18:02 UTC+1, [email protected] wrote: > > Thanks for the suggestions, Michael. I've been thinking about the problem > some more, and I think the most sound solution to bring all the logic > together is to write an Ansible module and throw it in with any roles that > require AUR package installation. I'm going to have a closer look at > Ansible's pacman module to get an idea of where to start, but in case > anyone else is thinking about this problem, I'll share my thoughts so far. > Feel free to point out any holes or logical inconsistencies in my plan. > > 1. tell the module where the PKGBUILD is on the target system. > Presumably it would be placed there by the unarchive or copy modules. > 2. parse PKGBUILD for crucial variables (package name, epoch, rel, > version). Luckily a PKGBUILD is a bash script, and whitespace is forbidden > in those variables, so simple grep/regex is sufficient > 3. pacman -Q packagename to determine if the package is already > installed and, if so, what version it is. If it's not installed then we > already know it has to be installed, otherwise we compare versions between > the PKGBUILD and the installed version to see which one is newer. (pacman > versions are epoch:version-rel syntax, similar to rpm and compared the > same > way) Technically it makes more sense to build the package and then use a > standard arch linux script to query the tarball's version, but we're > trying > to avoid building the package until it's clearly necessary. If the > installed version is up to date then we can stop here. > 4. assuming the package has to be installed (either it's not installed > on the target, or our PKGBUILD is newer), we have to get a pkg.tar.xz for > it. We can assemble the name of the package's tarball from the PKGBUILD > variables (I think it's packagename-epoch:ver-rel-architecture.pkg.tar.xz > but I can't remember for sure) and check if that file already exists. If > it > does then we'll assume it's the package tarball. Skip to step 5. (More on > this later) > 5. no tarball found? Guess we have to build it. makepkg -cs --asroot > --noconfirm in the PKGBUILD directory. -c to clean sources and -s to > install makedeps before building (I think we need to supply --noconfirm > with -s but can't remember). This is the most time consuming step so > obviously we're hoping we don't have to do this, but one way or another > this will put the tarball on our system. > 6. pacman -U --noconfirm on the tarball to install it. If we can't > find the tarball at this point then we assume it was a build failure. If > the installation fails then the tarball must have been broken for some > reason, install failure. If everything connects then the package has been > successfully installed. Work complete! > > Pros of this approach: > > - Don't have to build the package on the target. We can build it > somewhere else and then copy the tarball onto the target, and it'll just > use it as is. Huge savings for low-RAM ARM systems (build yourself with > distcc cross compilation and then just drop the tarball on the Ansible > slave). > - Don't have to leave the PKGBUILD on the system in a special > directory. One of my earlier ideas was to copy your PKGBUILD to the same > directory every time you run the playbook. If the copy action is skipped, > you know that the PKGBUILD is unchanged, so no rebuild is required. But > that requires a particular directory to store the PKGBUILD and other build > artifacts, which is not needed for this system. (Bonus: you can still > implement that behavior with the method I've described. Use unarchive or > copy to move the PKGBUILD to the target, and if the action was skipped, > then skip the AUR module as well.) > - No rebuild for packages that are already up to date! This was the #1 > requirement of my plan. > > Anyway I will see what I can do to implement this behavior in the near > future. Long term goal would be to get this merged into the pacman module, > but let's start small. > > > On Friday, July 11, 2014 6:32:44 PM UTC-4, Michael DeHaan wrote: >> >> For your first bullet point, consider running a command to see if >> "whatever" is installed/ready, using facts, or shell+register. >> >> Then use "group_by" to select the machines that don't have that criteria >> set that one way. >> >> You can then skip configuration on those systems where things are already >> done. >> >> >> >> >> On Thu, Jul 10, 2014 at 11:27 PM, <[email protected]> wrote: >> >>> As the title says, I'm wondering if anyone has experience managing AUR >>> packages with Ansible. I'm personally interested in nginx-passenger, but >>> the question could really apply to any AUR package. Unlike official >>> packages, AUR packages have to be built by the user, which introduces a >>> slew of problems: >>> >>> - knowing when to build the package. I'd say it's pretty much a given >>> that the package has to be built on the target system. However, I'm >>> provisioning ARM single-board computers with Ansible, and compiling nginx >>> on a system with a 1GHz processor and 1GB of memory is a painful >>> experience. I don't want to do it any more often than necessary. >>> - knowing whether or not the package is installed, and whether or not >>> the installed version is up to date. The existing pacman module in Ansible >>> (thumbs up for actually having a module, by the way. as an Arch user I was >>> glad to see it) can query if a package is installed via state=present, but >>> if the package isn't installed then it will obviously try to install it. >>> That will fail because AUR packages aren't hosted on official repositories. >>> >>> Any thoughts or suggestions? One thing I just thought of, while writing >>> this, was to set up yaourt on the target system, since it would seamlessly >>> integrate AUR installation, but I have literally zero experience with >>> yaourt. Plus this kind of introduces a chicken-and-egg problem - to install >>> one AUR package, I first have to install another AUR package, which goes >>> right back to the original issue. >>> >>> I do speak a little python, so I'm not averse to submitting a PR for >>> this issue, if someone has a good idea for how to implement it. I'm at a >>> loss for now. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Ansible Project" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/ansible-project/41c041b8-7a5a-4190-87e2-01a4e470c9a5%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/ansible-project/41c041b8-7a5a-4190-87e2-01a4e470c9a5%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/29a7e3cb-b2e8-4dfc-a133-b5a010526a5d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
