- From: dreamcat four <
>
- To:
- Subject: [chef] Re: Re: [RFC] CHEF-50 - Portage use flags & keywords
- Date: Mon, 8 Feb 2010 22:27:31 +0000
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=Yo1mnfFDQbepqOL9i39caYVLWhnYjj1BlXztqvNQWLn0dXoqg6+KfMEA/5k9w8Dnhn BMXheSbYkPv4OjTbERSiStFvg9VbHexlJkZh12eVdz+F+cRQ/Zw3qu+b3cw8ZX4Xt/kA xlGNesf17aLDRzKlOLE+2A7d4f6ZjEorsx1NI=
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
<
>
wrote:
>
On Mon, Feb 8, 2010 at 4:24 AM, Kenneth Kalmer
>
<
>
>
wrote:
>
> Currently Chef::Resource::Package doesn't give us the ability to pass
>
> arbitrary attributes that can be used by Chef::Provider::Package::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:
>
>
Archive powered by MHonArc 2.6.16.