Re: [gentoo-dev] Re: [gentoo-council] pkg_pretend USE validation and VALID_USE alternative

On 04/01/2010 01:44 PM, Róbert Čerňanský wrote: > If I'm getting this right the proposed behavior is such that in case of > conflicting use flags emerge fails and user gets a message that he > has to set use flags as required. If so then I think it is not the right > way to handle it. A package man

Re: [gentoo-dev] Re: [gentoo-council] pkg_pretend USE validation and VALID_USE alternative

On Wed, 31 Mar 2010 03:46:47 -0700 Brian Harring wrote: > > On Wed, Mar 31, 2010 at 11:48:37AM +0200, Ulrich Mueller wrote: > > > On Wed, 31 Mar 2010, Brian Harring wrote: > > > > | Occasionally, ebuilds will have conflicting USE flags for > > | functionality. Checking for them and returnin

[gentoo-dev] Re: [gentoo-council] pkg_pretend USE validation and VALID_USE alternative

>> | Occasionally, ebuilds will have conflicting USE flags for >> | functionality. Checking for them and returning an error is not a >> | viable solution. Instead, you must pick one of the USE flags in >> | conflict to favour. >> >> [1] > >

[gentoo-dev] Re: [gentoo-council] pkg_pretend USE validation and VALID_USE alternative

Note I inadvertantly cross posted, I was intending on cc'ing coun...@gentoo.org. As such one final cc to that ml to end this subthread while pulling this back to -dev. On Wed, Mar 31, 2010 at 11:16:22PM +1300, Alistair Bush wrote: > > Hola all- > > > > Comments desired; assuming no significa

[gentoo-dev] Re: [gentoo-council] pkg_pretend USE validation and VALID_USE alternative

Note that while I inadvertantly cross posted (I was intending on cc'ing coun...@gentoo.org, not the ml), doubt they need to be cc'd further- my original attention was to effectively ensure they were paying aware of the details of this so that when I took it to them folk were informed. CC'ing g

[gentoo-dev] Re: [gentoo-council] pkg_pretend USE validation and VALID_USE alternative

> On Wed, 31 Mar 2010, Brian Harring wrote: > Roughly, VALID_USE is a list of constraints stating what the allowed > use flag combinations are for this pkg. If you think of normal > depdencies (I must have openssl and python merged prior), it's the > same machinery. Maybe we should first disc