From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.43) id 1E5owV-0002S7-5b for garchives@archives.gentoo.org; Thu, 18 Aug 2005 18:16:43 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j7IIG3Ik016310; Thu, 18 Aug 2005 18:16:03 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j7IIEMYq019938 for ; Thu, 18 Aug 2005 18:14:22 GMT Received: from cpe-65-26-255-237.wi.res.rr.com ([65.26.255.237] helo=nightcrawler) by smtp.gentoo.org with esmtpa (Exim 4.43) id 1E5ouE-0000rp-B0 for gentoo-dev@lists.gentoo.org; Thu, 18 Aug 2005 18:14:22 +0000 Date: Thu, 18 Aug 2005 13:13:56 -0500 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] ebuild design issue regarding some {I need the lib and api only}-DEPENDs Message-ID: <20050818181355.GF19947@nightcrawler> References: <200508181628.44059.trapni@gentoo.org> <200508181040.46106.vapier@gentoo.org> <4304A59D.8050901@gentoo.org> <1124379426.21223.155.camel@cgianelloni.nuvox.net> <20050818155606.GB19947@nightcrawler> <20050818182403.4291726c@snowdrop.home> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kR3zbvD4cgoYnS/6" Content-Disposition: inline In-Reply-To: <20050818182403.4291726c@snowdrop.home> User-Agent: Mutt/1.5.8i X-Archives-Salt: e4a85d79-1478-42be-8702-fe9fb519d70a X-Archives-Hash: 08d42fd6554984adcc834e3ca7f174b7 --kR3zbvD4cgoYnS/6 Content-Type: text/plain; charset=utf8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 18, 2005 at 06:24:03PM +0100, Ciaran McCreesh wrote: > On Thu, 18 Aug 2005 10:56:06 -0500 Brian Harring > wrote: > | Best solution in my opinon? Two use flags address this, client, and=20 > | server. Regardless of the setting of the two, you get the library;=20 > | from there, you just set client and server as defaulting to on, and=20 > | packages use dep on whatever chunk of it they need (quite likely no=20 > | use dep in this case, since they probably only need the lib). >=20 > We went over this already. Englighten me, since the issues I'm groking from this I'm fairly sure=20 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=20 referencing doing the changes now, and sticking a die in, I already =20 explicitly stated the responsible party would need a wedgie if it was=20 done; the "lets check for use flags on our deps in pkg_setup" is evil=20 as hell, and *only* should be used when absolutely explicitly required.=20 iow, wait for use deps unless you've got some damn good reason to=20 fall back to the kludge while waiting. Other angle I see is if you're referencing naming the vars in=20 mutually exclusive use flags; if that's the case, I'll just point=20 out that the use flag names in the suggested solution aren't mutually=20 exclusive. Re: probably, it's a comment on the packages that depend on mysql;=20 will they 'probably' require the library (meaning no use dep with the=20 flag configuration above), or will they require the client and/or=20 server chunks (requiring use flags on). Not advocating loose depends if that's how you read it, just added=20 bonus for most packages that dep on mysql that it's use configuration=20 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=20 client/server breaks down as a global use flag :) Either way, in this case it *does* make sense, and going with any=20 *only style route makes the flags mutually exclusive (bad). So the=20 alternative names would have to be...? One comment on mutually exclusive use flags/confutils bit- I've asked=20 before and never gotten a decent response, but I'd like to see mutually=20 exclusive use flags represented somehow in an ebuild- preferably a=20 seperate metadata key, and probably requiring the addition of an=20 xor operator to dep syntax. Pretty much just represent the conflicts, and what flags are dependant=20 on one another. Bit ambivalent about that latter part however, since=20 I gtk/gtk2 interaction is a sore point in the tree from where I'm sit. ~harring --kR3zbvD4cgoYnS/6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDBM/jvdBxRoA3VU0RAlbYAJ9+FhrenIONeSSoeWxmZZmAhtdS4gCeKIa1 xIpCST3/BRwIG1ll0VEyC/0= =zjGn -----END PGP SIGNATURE----- --kR3zbvD4cgoYnS/6-- -- gentoo-dev@gentoo.org mailing list