public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
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 --]

  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