On Thu, Aug 18, 2005 at 06:24:03PM +0100, Ciaran McCreesh wrote: > On Thu, 18 Aug 2005 10:56:06 -0500 Brian Harring <[EMAIL PROTECTED]> > wrote: > | Best solution in my opinon? Two use flags address this, client, and > | server. Regardless of the setting of the two, you get the library; > | from there, you just set client and server as defaulting to on, and > | packages use dep on whatever chunk of it they need (quite likely no > | use dep in this case, since they probably only need the lib). > > We went over this already. Englighten me, since the issues I'm groking from this I'm fairly sure I already stated/covered :)
> We can't have client and server USE flags > because the meaning is totally different for every package. Plus the > 'probably' really isn't good enough, since there are some packages that > have more specific dependency and the current "die in pkg_setup" stuff > is a real pain -- do we really want to see that becoming a regular > occurrence? You're a bit vague in the 'die in pkg_setup' bit; if you're referencing doing the changes now, and sticking a die in, I already explicitly stated the responsible party would need a wedgie if it was done; the "lets check for use flags on our deps in pkg_setup" is evil as hell, and *only* should be used when absolutely explicitly required. iow, wait for use deps unless you've got some damn good reason to fall back to the kludge while waiting. Other angle I see is if you're referencing naming the vars in mutually exclusive use flags; if that's the case, I'll just point out that the use flag names in the suggested solution aren't mutually exclusive. Re: probably, it's a comment on the packages that depend on mysql; will they 'probably' require the library (meaning no use dep with the flag configuration above), or will they require the client and/or server chunks (requiring use flags on). Not advocating loose depends if that's how you read it, just added bonus for most packages that dep on mysql that it's use configuration wouldn't require use deps. > We can't have client and server USE flags > because the meaning is totally different for every package. Meh, I disagree without counter examples provided of where client/server breaks down as a global use flag :) Either way, in this case it *does* make sense, and going with any *only style route makes the flags mutually exclusive (bad). So the alternative names would have to be...? One comment on mutually exclusive use flags/confutils bit- I've asked before and never gotten a decent response, but I'd like to see mutually exclusive use flags represented somehow in an ebuild- preferably a seperate metadata key, and probably requiring the addition of an xor operator to dep syntax. Pretty much just represent the conflicts, and what flags are dependant on one another. Bit ambivalent about that latter part however, since I gtk/gtk2 interaction is a sore point in the tree from where I'm sit. ~harring
pgpS67k6LlDzV.pgp
Description: PGP signature
