Mailing List Archive

On 6/9/06, Chris Gianelloni <wolf31o2@gentoo.org> 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 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?

It means that different packages will behave differently throughout
the tree, but that's okay, and is more Gentoo-like than your proposal.

> To facilitate building the client portions only, the
> use of the local "minimal" USE flag is allowed.

How will you support building the server-only portions of the package?
I don't want clients I don't need on my servers. "client" and
"server" USE flags would appear to make much more sense here (for
packages that have any such clear distinction), and will play better
when USE-based DEPs become reality.

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list

On Fri, 2006-06-09 at 22:05 +0100, Stuart Herbert wrote:
> On 6/9/06, Chris Gianelloni <wolf31o2@gentoo.org> 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 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.

> It means that different packages will behave differently throughout
> the tree, but that's okay, and is more Gentoo-like than your proposal.

Except that you're just saying exactly what I said, just in different
words.

> > To facilitate building the client portions only, the
> > use of the local "minimal" USE flag is allowed.
>
> How will you support building the server-only portions of the package?

I honestly never bothered to consider it, and really don't care.
Someone else can come up with that idea. The problem with using two USE
flags is what do you do when someone chooses neither?

--
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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 operating procedure is to build packages as they were
> intended and packaged from upstream. This means if the client and the
> server for a particular package is in a single package, we should build
> both by default. To facilitate building the client portions only, the
> use of the local "minimal" USE flag is allowed. This can be shown in
> the openldap and dhcp ebuilds.

That is backwards however.
The first ebuild to take advantage of building server/client
was net-snmp and it uses minimal to build only the snmpd, snmptrapd.
Sense then others have been bastardizing the USE flag.

Being that net-snmp was historically first in doing this I'd rather
not have to change all my setups on all my servers to accommodate your
idea of inverting the logic of declaring it minimal to mean client-only.

> Each package which uses this flag should
> document what is built when the "minimal" USE flag is in use, via
> use.local.desc as it will remove any ambiguity into what is being done.
> Because of this, I would request that "minimal" not become a global USE
> flag, since its meaning would actually be different between some
> packages,

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.

-peace


--
Ned Ludd <solar@gentoo.org>
Gentoo Linux

--
gentoo-dev@gentoo.org mailing list

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 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

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 me.

Sincerely,
Brix
--
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

Hi Chris,

On 6/9/06, Chris Gianelloni <wolf31o2@gentoo.org> 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@gentoo.org mailing list

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.
>
> 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

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 read

if use client || ! use server ; then
# build client
fi
if use server || ! use client ; then
# build server
fi

How does portage stop us from doing that now?

--
Roy Marples <uberlord@gentoo.org>
Gentoo/Linux Developer (baselayout, networking)
--
gentoo-dev@gentoo.org mailing list

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 client-only.
>>
>>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
>
>
> 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 read
>
> if use client || ! use server ; then
> # build client
> fi
> if use server || ! use client ; then
> # build server
> fi
>
> How does portage stop us from doing that now?
>

built_with_use is then incorrect, since for -client -server you really
built both.
--
gentoo-dev@gentoo.org mailing list

> 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

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
http://dev.gentoo.org/~lu_zero

--
gentoo-dev@gentoo.org mailing list

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 read
> >
> > if use client || ! use server ; then
> > # build client
> > fi
> > if use server || ! use client ; then
> > # build server
> > fi
> >
> > How does portage stop us from doing that now?
>
> built_with_use is then incorrect, since for -client -server you really
> built both.

use client && build client
use server && build server

The problem here is that breaks existing ebuilds, which could be viewed as
equally bad.

But technically built_with_use isn't incorrect as the ebuild wasn't built with
it. To effectively use built_with_use you cannot assume that the flag does
what it says on the tin - you have to inspect the ebuild code you're
querying.

Prior history shows deps of db vs gdbm where if both or neither then db was
used, otherwise the flagged db was used.

Problems problems - soltutions that work with existing installs or do we just
bite the bullet and do

! use client && ! use server && die "must select either client or server"

Which kinda defeats the purpose of a clean install.

--
Roy Marples <uberlord@gentoo.org>
Gentoo/Linux Developer (baselayout, networking)
--
gentoo-dev@gentoo.org mailing list

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 +client +server to mean the same thing?
> > > If so the logic can read
> > >
> > > if use client || ! use server ; then
> > > # build client
> > > fi
> > > if use server || ! use client ; then
> > > # build server
> > > fi
> > >
> > > How does portage stop us from doing that now?
> >
> > built_with_use is then incorrect, since for -client -server you really
> > built both.
>
> use client && build client
> use server && build server
>
> The problem here is that breaks existing ebuilds, which could be viewed as
> equally bad.
>
> But technically built_with_use isn't incorrect as the ebuild wasn't built with
> it. To effectively use built_with_use you cannot assume that the flag does
> what it says on the tin - you have to inspect the ebuild code you're
> querying.

> Prior history shows deps of db vs gdbm where if both or neither then db was
> used, otherwise the flagged db was used.

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 happens when
using the most recent ppc-uclibc stages which omitted a few entries
from the vdb. We end up having some ebuild or other assuming that
uclibc itself was built with +nls when it's really (-nls) use.masked
etc..



> Roy Marples <uberlord@gentoo.org>
> Gentoo/Linux Developer (baselayout, networking)
--
Ned Ludd <solar@gentoo.org>
Gentoo Linux

--
gentoo-dev@gentoo.org mailing list

On Sat, 10 Jun 2006 02:01:25 +0100
Roy Marples <uberlord@gentoo.org> 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 +client +server to mean the same
> > > thing? If so the logic can read
> > >
> > > if use client || ! use server ; then
> > > # build client
> > > fi
> > > if use server || ! use client ; then
> > > # build server
> > > fi
> > >
> > > How does portage stop us from doing that now?
> >
> > built_with_use is then incorrect, since for -client -server you
> > really built both.
>
> use client && build client
> use server && build server
>
> The problem here is that breaks existing ebuilds, which could be
> viewed as equally bad.

I do think we should avoid built_with_use where we can, as it causes
emerge to abort.

I still think this would be much better dealt with by splitting the
ebuilds and using the existing one to install both sub-ebuilds.
To my mind, building client or server is too big a split for USE flags
which control features of a package rather than pieces of it. I realise
that's not a clear distinction, but I think 'use client|server' is
different from 'use ipv6'. The latter, which is how I see most USE
flags that build stuff conditionally, is about including support for
something within the application/libraries built by the ebuild.
However USE client/server is about whether the apps/libraries are built
at all.

Suggestion was:
net-misc/dhcp-client
net-misc/dhcp-server
net-misc/dhcp - RDEPEND on -client and -server

This way, if something needs the server, they depend on dhcp-server.
If something needs the client, it depends on dhcp-client. If you need
both, depend on net-misc/dhcp. Over time, existing package depedencies
can be reduced from dhcp to dhcp-client or dhcp-server as appropriate.

The only objection I've seen so far to the split ebuild approach is that
if upstream intend the whole tarball to be installed then we should do
the same. I don't think that holds too much water;

1) The 'meta' build would provide the complete package as compiled
upstream anyway

2) Just because upstream provide everything in one tarball doesn't mean
upstream think you should necessarily install everything. Obvious
example here is KDE.

3) The use flag approach effectively splits the build anyway, so
there's not really any difference.

> But technically built_with_use isn't incorrect as the ebuild wasn't
> built with it. To effectively use built_with_use you cannot assume
> that the flag does what it says on the tin - you have to inspect the
> ebuild code you're querying.
>
> Prior history shows deps of db vs gdbm where if both or neither then
> db was used, otherwise the flagged db was used.
>
> Problems problems - soltutions that work with existing installs or do
> we just bite the bullet and do
>
> ! use client && ! use server && die "must select either client or
> server"
>
> Which kinda defeats the purpose of a clean install.
>


--
Kevin F. Quinn

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 instance, keeping
it in one ebuild outweights the advantage of a split ebuild in my eyes.

> This way, if something needs the server, they depend on dhcp-server.
> If something needs the client, it depends on dhcp-client. If you need
> both, depend on net-misc/dhcp. Over time, existing package depedencies
> can be reduced from dhcp to dhcp-client or dhcp-server as appropriate.

I doubt any package will ever depend on a dhcp server as such so that helps
the one ebuild argument.

I think I'll keep it as it now is - minimal use flag stops server
installation.

--
Roy Marples <uberlord@gentoo.org>
Gentoo/Linux Developer (baselayout, networking)
--
gentoo-dev@gentoo.org mailing list

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

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

Chris Gianelloni wrote:
> On Fri, 2006-06-09 at 22:05 +0100, Stuart Herbert wrote:
>
>> On 6/9/06, Chris Gianelloni <wolf31o2@gentoo.org> 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 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.
>
>
>> It means that different packages will behave differently throughout
>> the tree, but that's okay, and is more Gentoo-like than your proposal.
>>
>
> Except that you're just saying exactly what I said, just in different
> words.
>
>
>>> To facilitate building the client portions only, the
>>> use of the local "minimal" USE flag is allowed.
>>>
>> How will you support building the server-only portions of the package?
>>
>
> I honestly never bothered to consider it, and really don't care.
> Someone else can come up with that idea. The problem with using two USE
> flags is what do you do when someone chooses neither?
>
>
It will build the $UPSTREAM default?

And btw, i like the server and client use flag idea.

+1
--
gentoo-dev@gentoo.org mailing list

On Sat, 10 Jun 2006 05:44:41 -0400
Mike Frysinger <vapier@gentoo.org> 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 the results of built_with_use ...

well yeah, that's what I meant :P

--
Kevin F. Quinn

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.
>
> 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

Got an ETA?

The situation we have now is confusing, at best, to our users, and
something really should be done to resolve it. Waiting another 6 months
to a year, only to be able to use it with the particular portage
versions that support the proper EAPI for use-based dependencies is not
an optimal answer for our users, which is why I came up with the
proposal. Honestly, I don't care *what* is decided, so much as I want
to spark conversation and see *some* resolution come of it that is *at
least* consistent until use-based dependencies are a reality.

--
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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
>
> How does portage stop us from doing that now?

It doesn't. The problem comes in with the dependency resolver. The
only solution to this is checks using built_with_use in pkg_setup, which
is discouraged except where absolutely necessary, as it causes all of
the dependencies to be merged (incorrectly, possibly) before there is a
failure.

--
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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 client or server
> > > and how to allow for building client-only.
> >
> > 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
>
> Got an ETA?
>
> The situation we have now is confusing, at best, to our users, and
> something really should be done to resolve it.

sure, dont add support for the flags at all at this point, problem solved

USE=minimal has no real definition, no point in trying to iron one out imo
-mike

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 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 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
> >
> > Got an ETA?
> >
> > The situation we have now is confusing, at best, to our users, and
> > something really should be done to resolve it.
>
> sure, dont add support for the flags at all at this point, problem solved

You apparently missed that there already are packages in the tree using
these flags, as well as minimal.

This inconsistent usage is what I was trying to solve in the first
place.

--
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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 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 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
> > >
> > > Got an ETA?
> > >
> > > The situation we have now is confusing, at best, to our users, and
> > > something really should be done to resolve it.
> >
> > sure, dont add support for the flags at all at this point, problem solved
>
> You apparently missed that there already are packages in the tree using
> these flags, as well as minimal.

not really ... i'm fully aware of USE=server since ive used it myself

USE=client however doesnt exist, so you'd be incorrect there

> This inconsistent usage is what I was trying to solve in the first
> place.

with a stop gap measure ... i dont think this stop gap effort is worth the
extra time, especially since it'll be simply backed out of down the road
-mike