Kent Fredric posted on Sun, 18 Mar 2012 08:43:55 +1300 as excerpted:

> I think what would be more practical is a sane way to enable FEATURES=""
> on a per-package level like USE flags in portage, then you could enable
> FEATURES="test" for that one package and it would always build that
> package with USE="test"
> 
> Paludis does this already via an extended use.conf syntax:

> Perhaps portage does this already and I'm hiding under a rock, but I
> haven't seen it

What's you're definition of "sane"?  Does it include the
/etc/portage/package.env and/or /etc/portage/env/cat-egory/pkg files 
configuration options?

I've been using (and prefer) the latter for quite some time for various 
per-package settings (tho not the particular one in question here) 
without an issue.  The former is newer but somewhat more limited, to 
make.conf style direct variable assignments, while the latter allows full 
bash flexibility, which I take advantage of.

For example, the following /etc/portage/env/media-video/smplayer-0.6.9-r1 
allowed me to avoid editing the ebuild directly.  (IIRC it was a patch 
necessary to build the package with gcc-4.6.  I'm on smplayer-0.7.1 now, 
but the version-specific package-path limited deployment to just that one 
version.)

post_src_prepare () {
        sed -i '1i#define OF(x) x' src/findsubtitles/quazip/*.h
}


See the /etc/portage/package.env and /etc/portage/env/ sections of the 
portage (5) manpage for the details.

So... Does that fit your definition of "sane"? =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


Reply via email to