[chef] Re: Re: FreeBSD package provider, past and future

[David Miller < >]

Another fun BSD Port issue that Chef currently doens't handle is when the port name and package name differ.  At Dyn I've worked around this limitation with a monkey patch that we use that adds a port_name attribute to the package resource so that we can install packages where this is the case in an idempotent way.  The issue you run into is that if you specify the package name it can't find the package.  If you give it the port name then it fails to check if the package is already installed resulting in the package getting reinstalled on every chef run.

An example of this is the nrpe package.  It's port name is nrpe2.  To install this package the command that has to be run is "pkg-add -r nrpe2".  But if we run the command that the resource uses to check the installed version we get no output from "pkg_info -E nrpe2*".  But if we run "pkg_info -E nrpe*" we the the following slightly sanitized output: "nrpe-2.xx".

My monkey patch works around this by using the port_name to install the package and the package_name for everything else.  If there's interest in this patch I'll see if I can get the time approved to get the necessary rspec coverage to get this accepted upstream.  If the intent is to totally rewrite the freebsd_package resource then this is just another issue to keep in mind when designing/implementing it.

--
David

On Mon, Dec 16, 2013 at 5:12 PM, Julian C. Dunn < " target="_blank"> > wrote:

On Mon, Dec 16, 2013 at 5:02 PM, Bryan McLellan < "> > wrote:

> Isa Farnik was asking me today about the FreeBSD package provider and
> why it does all sorts of tomfoolery rather than just a pkg_add -r.
> It's been a while since I administered FreeBSD boxes, and it's been
> almost five years since I first wrote that provider for fun.
>
> My frail memory was that binary packages were a silly concept that
> nobody used. In trying to remember why, I see that FreeBSD 6.2 from
> 2007 [1] was the first release that included the ability to do a
> binary upgrade. The binary repositories were apparently offline for a
> while due to a security incident [2] and pkgng was written to "provide
> FreeBSD with a state-of-the-art binary package management system,
> something that has been sadly lacking throughout the existence of
> FreeBSD" [3].
>
> It seems to me that up until recently (FreeBSD 10 + pkgng), using
> ports was still the way to go if you wanted software. Unless you
> wanted to build all your own binary packages.
>
> Thoughts or corrections?

It seems like we should have two providers for FreeBSD, one for
packages and one for compiling things from source.

I've always preferred ports to "pkg_add -r" when administering FreeBSD
systems. The biggest reason is that often the packages are broken
(e.g. built with some libc or other nonsense that isn't the right
major version as the one on your system), or certain binary packages
don't exist as they are kernel-dependent (e.g. virtio-kmod)

We should probably also open a ticket for adding a pkgng provider to
Chef, as FreeBSD 10 is about to be released. I see a few floating
around the Internet [1]

BTW, in case folks didn't see, the Bento project [2] now ships
VirtualBox and VMWare baseboxes for FreeBSD 9.2. I am working on
FreeBSD 10 support.

- Julian

[1] https://gist.github.com/rottenbytes/3503596
[2] https://github.com/opscode/bento

--
[ Julian C. Dunn < "> >          * Sorry, I'm    ]
[ WWW: http://www.aquezada.com/staff/julian    * only Web 1.0  ]
[ gopher://sdf.org/1/users/keymaker/           * compliant!    ]
[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9       ]