Hi!
One reference I can think of is that "execute" resource has an
"environment" attribute. However thats not a feature of the package
resource.
I don't understand as much about this as I would like. But it seems
you cant use "options" here because these are package options which
are set elsewhere and not appended to the end of the command. Maybe
the portage tools could help you out a bit more by exposing some
helper commands to manipulate those configuration files. If yes then
it should be relatively straightforward.
Otherwise, for adding / subtracting some arbitrary lines to a config
file, I'm not sure that's so well catered for in chef. Mainly we rely
on erb templates instead. Which may not be ideal.
In spirit I agree with Adam that its better to make and use a
platform-generic interface wherever possible to set these options. Its
easier to understand and to document those features in a more uniform
way.
For example:
If I were familiar with the Macports packaging system, I would know
that each package can be compiled with certain flavors, known as
"variants". However the "variants" feature is unique to Macports and
its either not used or called by that name on any other platforms.
But it could still seem reasonable and concise to write:
package "git-core" do
case node[:platform]
when "mac_os_x"
options "+bash_completion +svn"
end
end
It seems a lot harder to make such an elegant solution here. There
might be other ways. If you had made a seperate resource for these
hints things, then you could point it to your package resource with
notifies. Or you can write some overloaded resource methods into a
cookbook, which cater specifically for these tougher stuff (what I
would call the more "niche" behaviour). Hmm. Dunno.
On Mon, Feb 8, 2010 at 8:56 PM, Adam Jacob adam@opscode.com wrote:
On Mon, Feb 8, 2010 at 4:24 AM, Kenneth Kalmer kenneth.kalmer@gmail.com wrote:
Currently Chef::Resource::Package doesn't give us the ability to pass
arbitrary attributes that can be used by Chef::Provider:
:Portage to
manipulate the USE & KEYWORDS environment variables.
I can think of three possible routes to follow here, outlined below:
The first is to expand Chef::Resource::Package to accept a hash of
environment variables that can be passed to the underlying package
providers. This is generic enough, and could be used by other providers as
well:
package "net-dns/pdns" do
action :install
environment "USE" => "mysql"
end
The above can then be interpreted by the Portage provider and executed as
"USE=mysql emerge net-dns/pdns"
The second could be to implement two new providers specifically for Gentoo,
one for manipulating use flags and the other for manipulating keywords (both
through the corresponding /etc/portage/package.{use|keywords} files
use "net-dns/pdns" do
flags "mysql"
end
keywords "dev-db/couchdb" do
accept "~x86"
end
The last, and least desirable option would be to expand
Chef::Resource::Package to accept 'use' and 'keywords' as attributes, but
that blows it open to expansion from every child provider.
I would prefer not to have the generic terms "use" and "keywords" be
tied to this. It seems like this is indeed package-level options,
that just happen to set some things in the filesystem for you prior to
packaging.
My gut says the thing to do is to have a re-usable generic for hints
of this kind to the underlying package providers. One of the prime
reasons people choose one system over another are exactly this kind of
implementation detail - you pick Gentoo partly because you love the
use and keywords systems. Something like:
package "dev-db/couchdb" do
hints :keywords => { :accept => "~x86" }
end
Might work, and the underlying package provider can choose to do with
it as it will.
Another option would be to make these attributes available only
through the specific resource for the provider:
portage_package "dev-db/couchdb" do
keywords :accept => "~x86"
use :flags => "mysql"
end
You could build the nicer version (with the keywords and use
attributes) as sugar on top of the generic hints attribute.
Thoughts?
Adam
--
Opscode, Inc.
Adam Jacob, CTO
T: (206) 508-7449 E: adam@opscode.com
:Portage to