[chef] chef support on freebsd is subpar

[Sig Lange < >]

Fellow Chefs,

I've encountered a few problems with chef on freebsd.

I wanted to bring some awareness to the community to gauge freebsd
usage with chef.

I know that freebsd is not likely as popular as other distributions
but if functionality for such platform
is included (and touted as supported) it should at least be functional.

Here is a list of issues i've encountered. Some bugs. Some
questionably achievable by other means.
But as I see it, expected behavior is wrong.



1. assumptions are made on package names in ports versus package names
that are built using 'make package'
   Goal: Install apache
   Many variations of package are supported in the provider like URL,
FTP, from ports using whereis, absolute port path

   in my environment $PACKAGESITE is exported so pkg_add -r XXXX can
install a binary if available.

   Apache can only be installed via a URL with a version # and
architecture hard coded in.
   all fail due to the ports package differing then the package installed.

   a. package "apache22"
      Bails since the installed package name differs then the ports name.
      installed package name: apache-2.2.11_7
      ports package name: "apache22"

     Incorrectly tries to fetch (it's a 404):
http:///freebsd/ports/amd64/packages-7.2-release/Latest/apache22.tbz

   b. package "apache"
       Bails since make -V PORTVERSION XXX is used to determine
version. This is not a name of a valid port.


   c. package "/usr/ports/www/apache22"
       just like 1.a, Incorrectly tries to fetch (it's a 404):
http:///freebsd/ports/amd64/packages-7.2-release/Latest/apache22.tbz

    d.
        package "apache22" do
           source 
"http://XXX/freebsd/ports/amd64/packages-7.2-release/Latest/";
        end

   I'm not sure what the right solution here to maintain a "repository"
   Since the ports package name differs then the installed package
name one must manually symlink
   the tbz to a name that is being interpreted  and also is a valid
port name on the system.

   It seems like 1.a and 1.c are closest to functional if the packaged
name matched what was trying to be fetched.


2. package version parsing is just plain wrong.

   a version is detected by prefix and - so any package name with a
dash in it similiar to another will fail to
   install.  ie, protobuf and protobuf-c

--- recipe ---

package "protobuf"

--- chef run ---

[Tue, 21 Sep 2010 07:56:43 -0700] DEBUG: Processing package[protobuf]
[Tue, 21 Sep 2010 07:56:43 -0700] DEBUG: package[protobuf] using
Chef::Provider::Package::Freebsd
[Tue, 21 Sep 2010 07:56:43 -0700] DEBUG: Current version is c-0.14
[Tue, 21 Sep 2010 07:56:43 -0700] DEBUG: Ports candidate version is 2.1.0

--- debug ---
$ pkg_info |grep protobuf
protobuf-c-0.14     C bindings for Google's Protocol Buffers
py25-protobuf-2.1.0 Google protobuf Python Client Library


Well obviously c-0.14 is not a version for protbuf. The regular
expression is greedy when it should not be.

In 
/usr/local/lib/ruby/gems/1.8/gems/chef-0.7.16/lib/chef/provider/package/freebsd.rb

Chef does this to determine candidate version
$ make -V PORTVERSION -C /usr/ports/devel/protobuf
2.1.0

And does this to determine current version
$ pkg_info -E protobuf\*
protobuf-c-0.14


It does not bother to parse the package properly and get the
package_name and assert it
matches before returning the version.

line ~34
WRONG:
              when /^#{package_name}-(.+)/

Something like this has worked for me:
              when /^#{package_name}-([^-]+)$/


3. Typos is package provider exception handling
Various places in chef package provider typo'd the exception name
space for package.

Chef::Exception::Package is used instead of Chef::Exceptions::Package

So meaningful error messages are suppressed with a unknown constant error



Hope this helps anyone attempting to use freebsd in the future.

Cheers,

~ Sig