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

[Stuart Herbert]

Hi Chris,

On 6/9/06, Chris Gianelloni <wolf31o2@g.o> wrote:
> > > This means if the client and the
> > > server for a particular package is in a single package, we should build
> > > both by default.
> >
> > No thanks.  That doesn't match the standard operating procedure
> > mentioned above.  By default, why don't we just build whatever
> > $UPSTREAM intended built by default?
>
> That is *exactly* what I said.

Sorry, that's not how I read it.  I read you saying that, if $UPSTREAM
ship both server/client in a single package, we should build both.  I
didn't grok that as being the same as building whatever $UPSTREAM
indented being built by default.

For example, let's say package 'foo' has both client and server code
in the one package, but running ./configure w/ no parameters only
enables the client.  This is the behaviour I believe we should be
following.  From what you said in your initial email, I understood
that you'd like to see both server and client enabled, regardless of
what running ./configure w/ no parameters would enable.

Seems to be a mis-communication here.

> > How will you support building the server-only portions of the package?
> I honestly never bothered to consider it, and really don't care.

I'm sorry to hear that :(

> Someone else can come up with that idea.  The problem with using two USE
> flags is what do you do when someone chooses neither?

This is easily solved by the IUSE requested functionality for Portage,
so that each ebuild can propose a default set of USE flags.  If the
user ends up switching off all required USE flags, this should be
detected, and the emerge should refuse to proceed.  (Why? Because
otherwise USE-based DEPs can't work deterministically).

Ciaran filed a bug about what we'd need a year or so back.

Best regards,
Stu
-- 
gentoo-dev@g.o mailing list