Re: [gentoo-dev] ebuild design issue regarding some {I need the lib and api only}-DEPENDs

2005-08-18 Thread Brian Jackson
Use INSTALL_MASK to keep /usr/bin/mysqld or whatever from getting installed. We aren't generally in the habit of splitting packages into a bunch of different ebuilds. There are exceptions, but --Iggy Christian Parpart wrote: Hi all, well, regarding the request on bug 88490 [1] (and my

Re: [gentoo-dev] ebuild design issue regarding some {I need the lib and api only}-DEPENDs

2005-08-18 Thread Lance Albertson
Mike Frysinger wrote: On Thursday 18 August 2005 10:28 am, Christian Parpart wrote: Do we have a general accepted gentoo policy for this? general policy is to not split packages (and i agree with this ...) bind and bind-tools is split ;) Why is it so bad to split packages? (I'm just

Re: [gentoo-dev] ebuild design issue regarding some {I need the lib and api only}-DEPENDs

2005-08-18 Thread Ciaran McCreesh
On Thu, 18 Aug 2005 10:13:33 -0500 Lance Albertson [EMAIL PROTECTED] wrote: | bind and bind-tools is split ;) Why is it so bad to split packages? | (I'm just curious) Seems a bit odd that we can't have a library only, | client only, etc package like the other distros. Of course, I | understand

Re: [gentoo-dev] ebuild design issue regarding some {I need the lib and api only}-DEPENDs

2005-08-18 Thread Francesco R
Luca Barbato wrote: Christian Parpart wrote: Using the minimal useflag for this - IMHO - is a misuse of the idea of minimal semantically - as I do understand minimal in a way like don't overbloat me with patches and other feature additions-alike. minimal is about keeping the package

Re: [gentoo-dev] ebuild design issue regarding some {I need the lib and api only}-DEPENDs

2005-08-18 Thread Chris Gianelloni
On Thu, 2005-08-18 at 10:17 -0500, Brian Harring wrote: 2) ebuild maintenance will be a nightmare- every new version will require again walking the source to see if the lines you've drawn for dividing the source are still proper. This is another good point. I have two split packages

Re: [gentoo-dev] ebuild design issue regarding some {I need the lib and api only}-DEPENDs

2005-08-18 Thread Francesco R
Lance Albertson wrote: Mike Frysinger wrote: On Thursday 18 August 2005 10:28 am, Christian Parpart wrote: Do we have a general accepted gentoo policy for this? general policy is to not split packages (and i agree with this ...) bind and bind-tools is split ;) Why is it

Re: [gentoo-dev] ebuild design issue regarding some {I need the lib and api only}-DEPENDs

2005-08-18 Thread Brian Harring
On Thu, Aug 18, 2005 at 11:37:05AM -0400, Chris Gianelloni wrote: Other distributions are also binary-only, so there's no real comparison here. While I think having client and server type USE-flags is really a bad idea, I don't see a problem with providing a library. I 100% disagree with

Re: [gentoo-dev] ebuild design issue regarding some {I need the lib and api only}-DEPENDs

2005-08-18 Thread Ciaran McCreesh
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

Re: [gentoo-dev] ebuild design issue regarding some {I need the lib and api only}-DEPENDs

2005-08-18 Thread Brian Harring
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

Re: [gentoo-dev] ebuild design issue regarding some {I need the lib and api only}-DEPENDs

2005-08-18 Thread Brian Harring
On Fri, Aug 19, 2005 at 01:06:35AM +0100, Ciaran McCreesh wrote: On Thu, 18 Aug 2005 13:13:56 -0500 Brian Harring [EMAIL PROTECTED] wrote: | 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

Re: [gentoo-dev] ebuild design issue regarding some {I need the lib and api only}-DEPENDs

2005-08-18 Thread Christian Parpart
On Thursday 18 August 2005 19:01, Georgi Georgiev wrote: maillog: 18/08/2005-16:28:40(+0200): Christian Parpart types Using the minimal useflag for this - IMHO - is a misuse of the idea of minimal semantically - as I do understand minimal in a way like don't overbloat me with patches and

Re: [gentoo-dev] ebuild design issue regarding some {I need the lib and api only}-DEPENDs

2005-08-18 Thread Christian Parpart
On Thursday 18 August 2005 17:44, Chris Gianelloni wrote: On Thu, 2005-08-18 at 10:17 -0500, Brian Harring wrote: 2) ebuild maintenance will be a nightmare- every new version will require again walking the source to see if the lines you've drawn for dividing the source are still

Re: [gentoo-dev] ebuild design issue regarding some {I need the lib and api only}-DEPENDs

2005-08-18 Thread Luke-Jr
On Thursday 18 August 2005 17:01, Georgi Georgiev wrote: vanilla - Do not add extra patches which change default behaviour For features, I would expect individual USE flags-- what if I want one patch, but not another? For changing mere defaults, a gentoo USE flag seems like it would make

Re: [gentoo-dev] ebuild design issue regarding some {I need the lib and api only}-DEPENDs

2005-08-18 Thread Brian Harring
On Fri, Aug 19, 2005 at 05:30:42AM +0200, Christian Parpart wrote: On Thursday 18 August 2005 17:44, Chris Gianelloni wrote: On Thu, 2005-08-18 at 10:17 -0500, Brian Harring wrote: 2) ebuild maintenance will be a nightmare- every new version will require again walking the source to see

Re: [gentoo-dev] ebuild design issue regarding some {I need the lib and api only}-DEPENDs

2005-08-18 Thread Georgi Georgiev
maillog: 19/08/2005-02:59:46(+): Luke-Jr types On Thursday 18 August 2005 17:01, Georgi Georgiev wrote: vanilla - Do not add extra patches which change default behaviour For features, I would expect individual USE flags-- what if I want one patch, but not another? I agree.