From: Brian Harring <ferringb@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] ebuild design issue regarding some {I need the lib and api only}-DEPENDs
Date: Thu, 18 Aug 2005 13:13:56 -0500 [thread overview]
Message-ID: <20050818181355.GF19947@nightcrawler> (raw)
In-Reply-To: <20050818182403.4291726c@snowdrop.home>
[-- Attachment #1: Type: text/plain, Size: 3045 bytes --]
On Thu, Aug 18, 2005 at 06:24:03PM +0100, Ciaran McCreesh wrote:
> On Thu, 18 Aug 2005 10:56:06 -0500 Brian Harring <ferringb@gentoo.org>
> 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
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2005-08-18 18:16 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-18 14:28 [gentoo-dev] ebuild design issue regarding some {I need the lib and api only}-DEPENDs Christian Parpart
2005-08-18 14:23 ` Luca Barbato
2005-08-18 15:24 ` Francesco R
2005-08-18 14:27 ` Brian Jackson
2005-08-18 14:40 ` Mike Frysinger
2005-08-18 15:13 ` Lance Albertson
2005-08-18 15:24 ` Ciaran McCreesh
2005-08-18 15:28 ` Francesco R
2005-08-18 15:37 ` Chris Gianelloni
2005-08-18 15:56 ` Brian Harring
2005-08-18 16:08 ` [gentoo-dev] Local USE defaults Donnie Berkholz
2005-08-18 16:31 ` Brian Harring
2005-08-18 17:16 ` Alec Warner
2005-08-18 17:36 ` Brian Harring
2005-08-18 17:18 ` Mike Frysinger
2005-08-18 17:38 ` Brian Harring
2005-08-19 7:10 ` Donnie Berkholz
2005-08-19 11:53 ` Brian Harring
2005-08-18 17:24 ` [gentoo-dev] ebuild design issue regarding some {I need the lib and api only}-DEPENDs Ciaran McCreesh
2005-08-18 18:13 ` Brian Harring [this message]
2005-08-19 0:06 ` Ciaran McCreesh
2005-08-19 1:59 ` Brian Harring
2005-08-18 15:17 ` Brian Harring
2005-08-18 15:44 ` Chris Gianelloni
2005-08-19 3:30 ` Christian Parpart
2005-08-19 3:09 ` Brian Harring
2005-08-18 17:01 ` Georgi Georgiev
2005-08-19 2:59 ` Luke-Jr
2005-08-19 5:01 ` Georgi Georgiev
2005-08-19 3:19 ` Christian Parpart
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050818181355.GF19947@nightcrawler \
--to=ferringb@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox