Re: [gentoo-dev] [RFC] client/server policy for ebuilds

2006-06-14 Thread Mike Frysinger
On Monday 12 June 2006 08:23, Chris Gianelloni wrote: On Sat, 2006-06-10 at 19:56 -0400, Mike Frysinger wrote: On Saturday 10 June 2006 10:29, Chris Gianelloni wrote: On Fri, 2006-06-09 at 18:34 -0400, Mike Frysinger wrote: On Friday 09 June 2006 16:35, Chris Gianelloni wrote: This

Re: [gentoo-dev] [RFC] client/server policy for ebuilds

2006-06-10 Thread Kevin F. Quinn
On Sat, 10 Jun 2006 02:01:25 +0100 Roy Marples [EMAIL PROTECTED] wrote: On Saturday 10 June 2006 01:33, Alec Warner wrote: So we have two use flags - client and server. Here are the possabilities -client -server +client -server +client +server -client +server Do we

Re: [gentoo-dev] [RFC] client/server policy for ebuilds

2006-06-10 Thread Roy Marples
On Saturday 10 June 2006 09:32, Kevin F. Quinn wrote: Suggestion was: net-misc/dhcp-client net-misc/dhcp-server net-misc/dhcp - RDEPEND on -client and -server You would also need net-misc/dhcp-common then to stop client and server installing the same required libraries and headers. In this

Re: [gentoo-dev] [RFC] client/server policy for ebuilds

2006-06-10 Thread Mike Frysinger
On Friday 09 June 2006 21:27, Ned Ludd wrote: Maybe along the same lines as what you are pointing out here it should also be noted that built_with_use is semi faulty and can return wrong results when no /var/db/pkg/$CATEGORY/$PVR/USE exists. this is done on purpose -mike pgpkeT3VMXksr.pgp

Re: [gentoo-dev] [RFC] client/server policy for ebuilds

2006-06-10 Thread Mike Frysinger
On Saturday 10 June 2006 04:32, Kevin F. Quinn wrote: I do think we should avoid built_with_use where we can, as it causes emerge to abort. no it doesnt ... the ebuild maintainer makes the package abort based upon the results of built_with_use ... -mike pgpIaYYFHjNYa.pgp Description: PGP

Re: [gentoo-dev] [RFC] client/server policy for ebuilds

2006-06-10 Thread Luis Francisco Araujo
Chris Gianelloni wrote: On Fri, 2006-06-09 at 22:05 +0100, Stuart Herbert wrote: On 6/9/06, Chris Gianelloni [EMAIL PROTECTED] wrote: Gentoo's standard operating procedure is to build packages as they were intended and packaged from upstream. +1 This means if the client

Re: [gentoo-dev] [RFC] client/server policy for ebuilds

2006-06-10 Thread Kevin F. Quinn
On Sat, 10 Jun 2006 05:44:41 -0400 Mike Frysinger [EMAIL PROTECTED] wrote: On Saturday 10 June 2006 04:32, Kevin F. Quinn wrote: I do think we should avoid built_with_use where we can, as it causes emerge to abort. no it doesnt ... the ebuild maintainer makes the package abort based upon

Re: [gentoo-dev] [RFC] client/server policy for ebuilds

2006-06-10 Thread Chris Gianelloni
On Fri, 2006-06-09 at 18:34 -0400, Mike Frysinger wrote: On Friday 09 June 2006 16:35, Chris Gianelloni wrote: This is the official (hehe) request for comments on making a policy of how to handle ebuilds than can be used for either client or server and how to allow for building client-only.

Re: [gentoo-dev] [RFC] client/server policy for ebuilds

2006-06-10 Thread Chris Gianelloni
On Sat, 2006-06-10 at 01:24 +0100, Roy Marples wrote: Do we read -client -server and +client +server to mean the same thing? We could, yes. If so the logic can read if use client || ! use server ; then # build client fi if use server || ! use client ; then # build server fi

Re: [gentoo-dev] [RFC] client/server policy for ebuilds

2006-06-10 Thread Mike Frysinger
On Saturday 10 June 2006 10:29, Chris Gianelloni wrote: On Fri, 2006-06-09 at 18:34 -0400, Mike Frysinger wrote: On Friday 09 June 2006 16:35, Chris Gianelloni wrote: This is the official (hehe) request for comments on making a policy of how to handle ebuilds than can be used for either

[gentoo-dev] [RFC] client/server policy for ebuilds

2006-06-09 Thread Chris Gianelloni
This is the official (hehe) request for comments on making a policy of how to handle ebuilds than can be used for either client or server and how to allow for building client-only. The idea is quite simple. Gentoo's standard operating procedure is to build packages as they were intended and

Re: [gentoo-dev] [RFC] client/server policy for ebuilds

2006-06-09 Thread Stuart Herbert
On 6/9/06, Chris Gianelloni [EMAIL PROTECTED] wrote: Gentoo's standard operating procedure is to build packages as they were intended and packaged from upstream. +1 This means if the client and the server for a particular package is in a single package, we should build both by default. No

Re: [gentoo-dev] [RFC] client/server policy for ebuilds

2006-06-09 Thread Chris Gianelloni
On Fri, 2006-06-09 at 22:05 +0100, Stuart Herbert wrote: On 6/9/06, Chris Gianelloni [EMAIL PROTECTED] wrote: Gentoo's standard operating procedure is to build packages as they were intended and packaged from upstream. +1 This means if the client and the server for a particular

Re: [gentoo-dev] [RFC] client/server policy for ebuilds

2006-06-09 Thread Ned Ludd
On Fri, 2006-06-09 at 16:35 -0400, Chris Gianelloni wrote: This is the official (hehe) request for comments on making a policy of how to handle ebuilds than can be used for either client or server and how to allow for building client-only. The idea is quite simple. Gentoo's standard

Re: [gentoo-dev] [RFC] client/server policy for ebuilds

2006-06-09 Thread Mike Frysinger
On Friday 09 June 2006 16:35, Chris Gianelloni wrote: This is the official (hehe) request for comments on making a policy of how to handle ebuilds than can be used for either client or server and how to allow for building client-only. rather than moving to some sort of policy that satisfies no

Re: [gentoo-dev] [RFC] client/server policy for ebuilds

2006-06-09 Thread Henrik Brix Andersen
On Fri, Jun 09, 2006 at 06:19:53PM -0400, Ned Ludd wrote: Seems logical. But for what you are proposing I'd suggest not making USE of minimal at all for this. I'd rather see that flag reserved for mostly embedded alike use. Me too. A server/client set of USE flags seems more appropriate to

Re: [gentoo-dev] [RFC] client/server policy for ebuilds

2006-06-09 Thread Luca Barbato
Mike Frysinger wrote: rather than moving to some sort of policy that satisfies no one completely and we'll have to back out of later, why dont we wait until portage can give us proper support for USE=client/server -mike +1 -- Luca Barbato Gentoo/linux Gentoo/PPC

Re: [gentoo-dev] [RFC] client/server policy for ebuilds

2006-06-09 Thread Roy Marples
On Friday 09 June 2006 23:34, Mike Frysinger wrote: On Friday 09 June 2006 16:35, Chris Gianelloni wrote: This is the official (hehe) request for comments on making a policy of how to handle ebuilds than can be used for either client or server and how to allow for building client-only.

Re: [gentoo-dev] [RFC] client/server policy for ebuilds

2006-06-09 Thread Alec Warner
Roy Marples wrote: On Friday 09 June 2006 23:34, Mike Frysinger wrote: On Friday 09 June 2006 16:35, Chris Gianelloni wrote: This is the official (hehe) request for comments on making a policy of how to handle ebuilds than can be used for either client or server and how to allow for building

Re: [gentoo-dev] [RFC] client/server policy for ebuilds

2006-06-09 Thread Stuart Herbert
How does portage stop us from doing that now? I don't think it does ... but you'll have to go back and clean it up when USE-based DEPs support eventually arrives. But we can worry about that nearer the time. Best regards, Stu -- gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] client/server policy for ebuilds

2006-06-09 Thread Roy Marples
On Saturday 10 June 2006 01:33, Alec Warner wrote: So we have two use flags - client and server. Here are the possabilities -client -server +client -server +client +server -client +server Do we read -client -server and +client +server to mean the same thing? If so the logic can

Re: [gentoo-dev] [RFC] client/server policy for ebuilds

2006-06-09 Thread Ned Ludd
On Sat, 2006-06-10 at 02:01 +0100, Roy Marples wrote: On Saturday 10 June 2006 01:33, Alec Warner wrote: So we have two use flags - client and server. Here are the possabilities -client -server +client -server +client +server -client +server Do we read -client -server and