FreeBSD package provider, past and future

Chef Infra (archive)
1

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?

Bryan

[1] http://www.freebsd.org/releases/6.2R/announce.html
[2] http://www.freebsdnews.net/2012/11/20/security-incident-freebsd-infrastructure/
[3] https://wiki.freebsd.org/pkgng/CharterAndRoadMap

2

On Mon, Dec 16, 2013 at 5:02 PM, Bryan McLellan btm@getchef.com 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] quick & dirty chef pkgng provider · GitHub
[2] GitHub - chef/bento: Packer templates for building minimal Vagrant baseboxes for multiple platforms

--
[ Julian C. Dunn jdunn@aquezada.com * Sorry, I'm ]
[ WWW: Julian Dunn's Blog - Commentary on media, technology, and everything in between. * only Web 1.0 ]
[ gopher://sdf.org/1/users/keymaker/ * compliant! ]
[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9 ]

3

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 jdunn@aquezada.com wrote:

On Mon, Dec 16, 2013 at 5:02 PM, Bryan McLellan btm@getchef.com 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] quick & dirty chef pkgng provider · GitHub
[2] GitHub - chef/bento: Packer templates for building minimal Vagrant baseboxes for multiple platforms

--
[ Julian C. Dunn jdunn@aquezada.com * Sorry, I'm ]
[ WWW: Julian Dunn's Blog - Commentary on media, technology, and everything in between. * only Web 1.0 ]
[ gopher://sdf.org/1/users/keymaker/ * compliant! ]
[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9 ]

4

On Mon, Dec 16, 2013 at 5:12 PM, Julian C. Dunn jdunn@aquezada.com wrote:

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

Looking briefly, it's not clear to me that they're really separate.
pkg_add installs a package made from ports, and pkg_add -r installs a
package made from ports that's in a remote repository. Until
pkgng/freebsd 10, it seems that freebsd is still really ports based.

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)

Right. I'm thinking about Gentoo with binary packages. It seems a lot
like binary packages are something you could do, not what you do.

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]

https://tickets.opscode.com/browse/CHEF-4637

Bryan