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

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

[Christian Parpart]

[-- Attachment #1: Type: text/plain, Size: 1208 bytes --]

Hi all,

well, regarding the request on bug 88490 [1] (and my own needs) I'm in a deep 
problem ;)

There *are* packages out there, that depend on (networking) client libraries 
(and their headers of course); 

for the general mysql ebuild, I'd propose the following splitup:
* dev-db/mysql-server (or myssqld)
* net-libs/libmysqlclient
* dev-db/mysql (a meta package that simply depends on both, for backward 
compat)

The reason is, that some packages need to talk to (SQL )servers, but some host 
installation do not need - or even want to (think about security policies) - 
a local (SQL) server;

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.

This idea of course is applicable for lots of more packages, but mysql is one 
use case where I myself ran into;

Do we have a general accepted gentoo policy for this?

And... any thoughts on this subject?

Regards,
Christian Parpart.

[1] http://bugs.gentoo.org/show_bug.cgi?id=88490
-- 
 15:56:43 up 148 days,  5:04,  2 users,  load average: 1.32, 1.21, 1.21

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Luca Barbato]

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 at the minimum, that means strip
every feature that won't prevent it to run.

> Do we have a general accepted gentoo policy for this?

Usually the policy is "If the upstream has planned that we'll follow,
otherwise no"

> 
> And... any thoughts on this subject?
> 

I'd prefer to have those features enabled by useflag, sometimes (eg.
qemu) I can split functionality in separated ebuild and use a metaebuild
to let users merge both w/out major overhead.

In your case a useflag IMHO would be enough since the situation require
a particular setup and in the case the constraint changes won't be a
problem rebuild a full mysql.

The question is, does the mysql configure script have a "clientonly"
and/or a "libraryonly" option?

There were a client and server useflag discussion before.

lu

-- 

Luca Barbato

Gentoo/linux Developer		Gentoo/PPC Operational Leader
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

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

[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 at the minimum, that means strip
>every feature that won't prevent it to run.
>
>  
>
Maybe it's foggy for mysql usage, better suggestions (clientonly, libonly) ?

>>Do we have a general accepted gentoo policy for this?
>>    
>>
>
>Usually the policy is "If the upstream has planned that we'll follow,
>otherwise no"
>  
>
[IMHO]
Upstream distribuite binaryes of only libraryes, in this direction it's
supported.
Build them from the source only libs is not deeply supported, see below.
[/IMHO]

>  
>
>>And... any thoughts on this subject?
>>
>>    
>>
>
>I'd prefer to have those features enabled by useflag, sometimes (eg.
>qemu) I can split functionality in separated ebuild and use a metaebuild
>to let users merge both w/out major overhead.
>
>In your case a useflag IMHO would be enough since the situation require
>a particular setup and in the case the constraint changes won't be a
>problem rebuild a full mysql.
>
>The question is, does the mysql configure script have a "clientonly"
>and/or a "libraryonly" option?
>  
>

there is an option for configure "--without-server" , but actually the
server is still build.
Take a look at >= dev-db/mysql-4.0.24-r2 for how "minimal" use flag is
used,
basically it force some flag off and remove some files from the install.

>There were a client and server useflag discussion before.
>
>lu
>
>  
>

-- 
gentoo-dev@gentoo.org mailing list

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

[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 own needs) I'm in a deep 
> problem ;)
> 
> There *are* packages out there, that depend on (networking) client libraries 
> (and their headers of course); 
> 
> for the general mysql ebuild, I'd propose the following splitup:
> * dev-db/mysql-server (or myssqld)
> * net-libs/libmysqlclient
> * dev-db/mysql (a meta package that simply depends on both, for backward 
> compat)
> 
> The reason is, that some packages need to talk to (SQL )servers, but some host 
> installation do not need - or even want to (think about security policies) - 
> a local (SQL) server;
> 
> 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.
> 
> This idea of course is applicable for lots of more packages, but mysql is one 
> use case where I myself ran into;
> 
> Do we have a general accepted gentoo policy for this?
> 
> And... any thoughts on this subject?
> 
> Regards,
> Christian Parpart.
> 
> [1] http://bugs.gentoo.org/show_bug.cgi?id=88490

-- 
I top post... suck it
-- 
gentoo-dev@gentoo.org mailing list

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

[Mike Frysinger]

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 ...)
-mike
-- 
gentoo-dev@gentoo.org mailing list

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

[Lance Albertson]

[-- Attachment #1: Type: text/plain, Size: 849 bytes --]

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 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 that
we could use useflags for that, but is that really the best solution for
 this particular issue?

Oh well, I'm just a sysadmin, not a coder so I'll got back to my cave. ;)

-- 
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1248 bytes --]

On Thu, 18 Aug 2005 10:13:33 -0500 Lance Albertson
<ramereth@gentoo.org> 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 that we could use useflags for that, but is that really
| the best solution for this particular issue?

We can't use USE flags because portage won't let us. There's been a bug
open about USE deps for yeaaaarrrrss.

Plus, the other issue... Say your package depends upon mysql, then
someone comes along and splits mysql via USE flags. You'll then need to
update your package to depend upon, say, mysql[client] because the
default behaviour will be to not require any particular USE flag to be
enabled.

TGL had a rather interesting proposal regarding 'parts', which are
similar to USE flags but the default behaviour is to depend upon a
package with all parts enabled unless explicitly indicated otherwise.
You may wish to find it and flesh it out some more.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[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 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 that
>we could use useflags for that, but is that really the best solution for
> this particular issue?
>
>Oh well, I'm just a sysadmin, not a coder so I'll got back to my cave. ;)
>
>  
>
vimdiff  bind-tools/bind-tools-9.2.5.ebuild bind/bind-9.2.5-r5.ebuild
In the eventuality of mysql being splitted the landscape is totally
different.
The code to duplicate is a 40% of the ebuild speaking of volume, in
maintenance the percentage is bigger.

I'm a (little) sysadmin too, redundancy is good speaking of servers but
maintain a cluster or simply to synced servers is more difficult (and
error prone) that maintain only one, right ?


-- 
gentoo-dev@gentoo.org mailing list

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

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 2053 bytes --]

On Thu, 2005-08-18 at 10:13 -0500, 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 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 that

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 splitting the package into client and server, but
don't think it would be bad to have it like this:

net-libs/libmysqlclient
dev-db/mysql

You'll notice that there is no server package.  The dev-db mysql package
should be the entire distribution.  Splitting out a separate library for
client-only shouldn't be too bad, but I still disagree with it, for the
most part.

> we could use useflags for that, but is that really the best solution for
>  this particular issue?

Honestly, we shouldn't be splitting packages like this.  If upstream has
a "--clientonly" or "--libsonly" configure option, that would be one
thing, but if they don't why should we split them up?  All it does is
increase the number of packages that would need to be updated for
security bugs and increase complexity, along with tree size.  We already
complain about not enough manpower.  Duplicating effort all over the
tree just to remove a few binaries from a system isn't a valuable use of
developer time, in my opinion.  This is especially true as we have
methods of masking things from being installed.

> Oh well, I'm just a sysadmin, not a coder so I'll got back to my cave. ;)

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1806 bytes --]

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 splitting the package into client and server, but
> don't think it would be bad to have it like this:
> 
> net-libs/libmysqlclient
> dev-db/mysql
> 
> You'll notice that there is no server package.  The dev-db mysql package
> should be the entire distribution.  Splitting out a separate library for
> client-only shouldn't be too bad, but I still disagree with it, for the
> most part.
Splitting it out is just as bad as breaking it into server/client 
chunks from the added QA and maintenance standpoint, thing is, in this 
case splitting out the lib *is* breaking it up into subpackages, so 
it's no better :)

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

Better tweak to it is not the usual use.defaults addition, but 
specifying the default state of the USE flag in IUSE, as proposed by 
spanky/others.

Kind of curious about people's opinion on the IUSE default use flag 
thing, initial syntax was (using the above example)
IUSE="+client server"
with client defaulting to on unless the user's config disables it- 
note, strictly enabling from IUSE, no auto-negation.
I forgot to add this, but it's a 10 line change if people still view 
it as worthwhile.
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Local USE defaults

[Donnie Berkholz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Brian Harring wrote:
| Kind of curious about people's opinion on the IUSE default use flag
| thing, initial syntax was (using the above example)
| IUSE="+client server"
| with client defaulting to on unless the user's config disables it-
| note, strictly enabling from IUSE, no auto-negation.
| I forgot to add this, but it's a 10 line change if people still view
| it as worthwhile.

Yes, very. Saves us from hacky local USE flag handling by naming them
no* or adding them to profiles.

Thanks,
Donnie
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDBLKTXVaO67S1rtsRAn5/AKCFdjpgmYOifvCOQ/zdRcwaN3S0cACgpuQq
y9G8JE3AF+J9AtMDFEYK74s=
=NbD3
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Local USE defaults

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1043 bytes --]

On Thu, Aug 18, 2005 at 09:08:51AM -0700, Donnie Berkholz wrote:
> Brian Harring wrote:
> | Kind of curious about people's opinion on the IUSE default use flag
> | thing, initial syntax was (using the above example)
> | IUSE="+client server"
> | with client defaulting to on unless the user's config disables it-
> | note, strictly enabling from IUSE, no auto-negation.
> | I forgot to add this, but it's a 10 line change if people still view
> | it as worthwhile.
> 
> Yes, very. Saves us from hacky local USE flag handling by naming them
> no* or adding them to profiles.
Which then raises the question of whether or not -* in a users USE 
should disable it.
I say no, since -* is mainly for killing off auto-use crap and 
profiles.

Note that explicitly disabling a flag (-client fex) would disable the 
default use there; question is whether or not some form of -* should 
exist for default IUSE; the existing -* is profile/autouse specific, 
and sholdn't be reused for disabling default IUSE imo.
yay/nay?
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Local USE defaults

[Alec Warner]

Brian Harring wrote:

>On Thu, Aug 18, 2005 at 09:08:51AM -0700, Donnie Berkholz wrote:
>  
>
>>Brian Harring wrote:
>>| Kind of curious about people's opinion on the IUSE default use flag
>>| thing, initial syntax was (using the above example)
>>| IUSE="+client server"
>>| with client defaulting to on unless the user's config disables it-
>>| note, strictly enabling from IUSE, no auto-negation.
>>| I forgot to add this, but it's a 10 line change if people still view
>>| it as worthwhile.
>>
>>Yes, very. Saves us from hacky local USE flag handling by naming them
>>no* or adding them to profiles.
>>    
>>
>Which then raises the question of whether or not -* in a users USE 
>should disable it.
>I say no, since -* is mainly for killing off auto-use crap and 
>profiles.
>
>  
>
As long as there is a way provided disable the 'default use flags' in 
this case referring to the IUSE="+foo" stuff, with a big warning that 
says crap generally isn't expected to work great with that setting on, 
then thats fine.  I can see something like a profile setting for this, 
since embedded may not want the same IUSE defaults as AMD64 
multilib...this also saves the profiles from becoming huge with "Hi turn 
this default flag off, and that flag off, and this flag on..." crud.

IMHO, it's really more of a profile setting anyhow, than a ebuild 
setting, although ebuilds could provide sensable defaults ( once again, 
making profiles smaller and less work for profile maintainers that don't 
deviate from the default much.

In any case both situations scream "hi I need tools cause I'm horribly 
complex and difficult to maintain properly".
-Alec Warner
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Local USE defaults

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1642 bytes --]

On Thu, Aug 18, 2005 at 01:16:05PM -0400, Alec Warner wrote:
> As long as there is a way provided disable the 'default use flags' in 
> this case referring to the IUSE="+foo" stuff, with a big warning that 
> says crap generally isn't expected to work great with that setting on, 
> then thats fine.  I can see something like a profile setting for this, 
> since embedded may not want the same IUSE defaults as AMD64 
> multilib...this also saves the profiles from becoming huge with "Hi turn 
> this default flag off, and that flag off, and this flag on..." crud.
See... -* shouldn't affect default IUSE.  Why?  Because if you make it 
flip off the ebuilds default use flags, you're forcing the ebuild to 
start using no* flags instead.  Ebuilds are unconfigured- there are 
default IUSE serves purely as a way for the ebuild maintainer to allow 
the ebuild to be broken down further- they can do it now, by adding a 
crapload of no* flags.

Allowing -* to castrate default IUSE forces them back into no* flags.

Literally, for the embedded example, they already probably have all of 
the no* flags flipped on if needed- an action was taken, you just 
change it so it's USE="-theflag" rather then USE="noflag".  Either 
way, the work involved is effectively the same.  Either way, profiles 
shouldn't be screwing with the ebuilds in that fashion imo.

Note this assuming this feature isn't used as a way to do 'suggested 
deps', where you start flipping on by default a lot of functionality 
the user didn't explicitly request (ala autouse).  A default of +perl 
on mysql I'd view as wrong, for example.
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Local USE defaults

[Mike Frysinger]

On Thursday 18 August 2005 12:31 pm, Brian Harring wrote:
> On Thu, Aug 18, 2005 at 09:08:51AM -0700, Donnie Berkholz wrote:
> > Brian Harring wrote:
> > | Kind of curious about people's opinion on the IUSE default use flag
> > | thing, initial syntax was (using the above example)
> > | IUSE="+client server"
> > | with client defaulting to on unless the user's config disables it-
> > | note, strictly enabling from IUSE, no auto-negation.
> > | I forgot to add this, but it's a 10 line change if people still view
> > | it as worthwhile.

add it like yesterday !

> > Yes, very. Saves us from hacky local USE flag handling by naming them
> > no* or adding them to profiles.
>
> Which then raises the question of whether or not -* in a users USE
> should disable it.
> I say no, since -* is mainly for killing off auto-use crap and
> profiles.

doesnt matter to me one way or the other ... may be confusing to users though 
who do `USE=-* emerge blah -pv` and see flags enabled
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Local USE defaults

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 966 bytes --]

On Thu, Aug 18, 2005 at 01:18:17PM -0400, Mike Frysinger wrote:
> > > Yes, very. Saves us from hacky local USE flag handling by naming them
> > > no* or adding them to profiles.
> >
> > Which then raises the question of whether or not -* in a users USE
> > should disable it.
> > I say no, since -* is mainly for killing off auto-use crap and
> > profiles.
> 
> doesnt matter to me one way or the other ... may be confusing to users though 
> who do `USE=-* emerge blah -pv` and see flags enabled
Yeah, but the angle I'm pushing for default IUSE's ...er.. use is 
eliminating no* flags, and giving ebuild maintainers more flexibility 
in breaking the package down into conditionals.

I really don't see -* being all that useful long term frankly, since 
the major usage of it I've seen is either within cascaded profiles, or 
nuking autouse; people do block profile use flags also, but killing 
autouse falls in with killing profiles :)
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Local USE defaults

[Donnie Berkholz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Brian Harring wrote:
| Yeah, but the angle I'm pushing for default IUSE's ...er.. use is
| eliminating no* flags, and giving ebuild maintainers more flexibility
| in breaking the package down into conditionals.
|
| I really don't see -* being all that useful long term frankly, since
| the major usage of it I've seen is either within cascaded profiles, or
| nuking autouse; people do block profile use flags also, but killing
| autouse falls in with killing profiles :)

I don't think that having -* not actually do -* is a good idea. And most
people adding local flags don't really consider the -* case so creating
no* flags isn't a major concern.

~From my POV, -* is expected to not work well, but it should do what it
suggests: subtract everything.

Thanks,
Donnie
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDBYX0XVaO67S1rtsRArRCAKCUEf96xd62wTe/Hh38P/+C5AQixACfcbaI
EtWc7AVEoSmegymfNCl6qcw=
=E/qT
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Local USE defaults

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1393 bytes --]

On Fri, Aug 19, 2005 at 12:10:44AM -0700, Donnie Berkholz wrote:
> Brian Harring wrote:
> | Yeah, but the angle I'm pushing for default IUSE's ...er.. use is
> | eliminating no* flags, and giving ebuild maintainers more flexibility
> | in breaking the package down into conditionals.
> |
> | I really don't see -* being all that useful long term frankly, since
> | the major usage of it I've seen is either within cascaded profiles, or
> | nuking autouse; people do block profile use flags also, but killing
> | autouse falls in with killing profiles :)
> 
> I don't think that having -* not actually do -* is a good idea. And most
> people adding local flags don't really consider the -* case so creating
> no* flags isn't a major concern.
> 
> ~From my POV, -* is expected to not work well, but it should do what it
> suggests: subtract everything.
Meh.
-* 's meaning right now is to nuke all USE flags that portage tries to 
'help' in adding.  Having it nuke all default use seems wrong, since 
people *currently* use -* to block autouse crap, and -* isn't what 
they signed up for initially.

Different flag imo seems wise, rather then grandfathering people into 
it; nuking what the profile offers should be available, but I don't 
think nuking default IUSE should be nuked as an added bonus of trying 
to disable auto-use/profile cruft.

Thoughts?
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 971 bytes --]

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

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Brian Harring]

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

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1334 bytes --]

On Thu, 18 Aug 2005 13:13:56 -0500 Brian Harring <ferringb@gentoo.org>
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 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.

For how many years have we been waiting for USE deps? I'd say that this
discussion is pretty much pointless. In the distant future when we do
get USE deps we'll no doubt have a whole different set of issues to
figure out.

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

Pretty much every case. It would never make sense to tinker with server
or client at a global level, so they'd be inappropriate as a global USE
flag.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 947 bytes --]

On Fri, Aug 19, 2005 at 01:06:35AM +0100, Ciaran McCreesh wrote:
> On Thu, 18 Aug 2005 13:13:56 -0500 Brian Harring <ferringb@gentoo.org>
> 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 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.
> 
> For how many years have we been waiting for USE deps? I'd say that this
> discussion is pretty much pointless. In the distant future when we do
> get USE deps we'll no doubt have a whole different set of issues to
> figure out.
USE deps have been sitting in core rewrite's cvs since monday.
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 3629 bytes --]

On Thu, Aug 18, 2005 at 04:28:40PM +0200, Christian Parpart wrote:
> for the general mysql ebuild, I'd propose the following splitup:
> * dev-db/mysql-server (or myssqld)
> * net-libs/libmysqlclient
> * dev-db/mysql (a meta package that simply depends on both, for backward 
> compat)

<snip- left for reference in following sections>

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

> 
> The reason is, that some packages need to talk to (SQL )servers, but some host 
> installation do not need - or even want to (think about security policies) - 
> a local (SQL) server;
> 
> 
> This idea of course is applicable for lots of more packages, but mysql is one 
> use case where I myself ran into;
> 
> Do we have a general accepted gentoo policy for this?
> 
> And... any thoughts on this subject?
We don't split upstream packages into seperate pieces normally, and 
without a damn good reason-

1) Upstream releases it combined.  Yes, this can be flawed if you're 
   the lucky maintainer of a package where upstream does stupid things as 
   routine, but we do try to have our ports of a package as 'true' to 
   upstream's original release as possible.

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.

3) Extension of #2, any source that's reliant on those lines you've 
   drawn to chunkify a package have to be verified everytime you change 
   the sets that the subpackages hold.

4) (not applicable here, but a point) chunkifying a package, assuming 
   you make it this far, is going to require configuration every run 
   through, or you'll have to write some script to store configuration on 
   the users box, and lift that (pkg-config plugin).  More work, and more 
   QA.

5) We already provide our own 'subpackages' in a sense; an 
   unconfigured ebuild can produce len(IUSE)^2 potential configurations 
   of itself, each effectively a subpackage that are all labelled as that 
   specific category/package-version.  Yes configured is a better term 
   there, but I'm trying to make a point here :P

Adding a use flag to control whether or not the server chunk gets 
installed I think is a great thing, but I also think there's no way in 
hell you should attempt it now- frankly, you can't do it now because 
use dependencies aren't available in any stable portage.

Yes, there is the pkg_setup die check for a use flag being no, and 
yes, anyone using that but in the most dire cases needs an atomic 
wedgie.  Too much stuff depends on mysql to resort to the pkg_setup 
hack, and mysql *is* a package that is a bit server centric normally, 
meaning those who hit the pkg_setup 'surprise' hopefully will hit it 
on a test server, rather then live.

People should use test servers rather then deploying changes they 
can't totally predict to a live server, but they don't, which kills 
that as an option.

Short version, control what gets installed via use flags, but don't 
introduce it until use deps are available in a stable portage.  
Breaking the beast up now is short sighted since use deps are 
already implemented in the core rewrite.  Yes, waiting is a pain in 
the ass, but the work to break it up and continue to indefinitely 
force subpackaging on an package isn't worth it.

My opinionated 2 cents...
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1738 bytes --]

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 that I maintain.
They are ut2004{,-data,-bonuspack-ece} and kudzu/libkudzu.  In my case,
the distinctions are actually quite easy, as ut2004-data pulls from the
CD, ECE pulls from a distfile (or the CD, with lots of detection-fu),
and ut2004 is an actual package of the latest patch files, not a
meta-package.  As for kudzu/libkudzu, the kudzu Makefile already has
this distinction built-in, so I don't have to maintain it myself.

I'd see no problem with this in mysql, if, for example, mysql's Makefile
had a "make libmysqlclient" target.  In that case, I would make it a
separate package.  This would also mean a lot of work on your part, as
every single package that had a dependency on mysql would now need some
way of specifying whether the server was going to be local or remote, to
properly *DEPEND on the correct package.

All in all, I think it isn't worth even attempting at this time.

> Short version, control what gets installed via use flags, but don't 
> introduce it until use deps are available in a stable portage.  
> Breaking the beast up now is short sighted since use deps are 
> already implemented in the core rewrite.  Yes, waiting is a pain in 
> the ass, but the work to break it up and continue to indefinitely 
> force subpackaging on an package isn't worth it.

Agreed.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Christian Parpart]

[-- Attachment #1: Type: text/plain, Size: 1848 bytes --]

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

minimize the duplication by a mysql eclass, just like we do for apache e.g. 
(and lots of others) that prevent us from code duplication.

> I'd see no problem with this in mysql, if, for example, mysql's Makefile
> had a "make libmysqlclient" target.  In that case, I would make it a
> separate package. 

Having a look at the already provided libmysqlclient ebuild [1] it obviousely 
(and for our luck) looks like upstream supports this installation types.

> This would also mean a lot of work on your part, as 
> every single package that had a dependency on mysql would now need some
> way of specifying whether the server was going to be local or remote, to
> properly *DEPEND on the correct package.

We've plenty of tools that help us in searching for all ebuilds *directly* 
depending on "dev-db/mysql"; than you just need to decide, wether this needs 
the server or not. And (w/o looking at them) I do predict, that 100% of them 
will only need libmysqlclient.

Why? What package would depend on the server in particular? If the user wants 
the server to be run on localhost, than he would just have to add it to his 
emerge args as well. I see no problems there - instead: it would be a great 
enheancement. (IMO)

> All in all, I think it isn't worth even attempting at this time.

read above. do you still think so? If so, why?

Regards,
Christian Parpart.

[1] http://bugs.gentoo.org/attachment.cgi?id=55816

-- 
 04:43:52 up 148 days, 17:51,  1 user,  load average: 0.66, 0.76, 1.15

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 2671 bytes --]

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 if the lines you've drawn for
> > >    dividing the source are still proper.
> 
> minimize the duplication by a mysql eclass, just like we do for apache e.g. 
> (and lots of others) that prevent us from code duplication.

Point was you would have to inspect each release to ensure it still 
fits.  If upstream does this for you, it's not any more of an issue 
then normal QA.
Yes this is being anal (re: the verification), but it's proper QA ultimately.

> > I'd see no problem with this in mysql, if, for example, mysql's Makefile
> > had a "make libmysqlclient" target.  In that case, I would make it a
> > separate package. 
> 
> Having a look at the already provided libmysqlclient ebuild [1] it obviousely 
> (and for our luck) looks like upstream supports this installation types.
Multiple configure/builds required- also is worth verifying that 
building the client/server against the lib does just that, uses 
existing on disk lib rather then rebuilding.

> Why? What package would depend on the server in particular? If the user wants 
> the server to be run on localhost, than he would just have to add it to his 
> emerge args as well. I see no problems there - instead: it would be a great 
> enheancement. (IMO)
> 
> > All in all, I think it isn't worth even attempting at this time.
> read above. do you still think so? If so, why?
Increased configuration run time per upgrades, two packages two 
maintain; why is that an issue?
1) dev-db/mysql must dep on the matching lib version.  $PV address 
   this, mostly.
2) 2 packages to handle in p.mask and for doing keywording changes
3) 2 packages to handle at the user side of things for 
   keywording/masking.

Real strong points I'm sure; key thing about all of this is that it's 
increased A) work, B) manual steps required (read: points of screwup).  
All of the args come down to that, extra complexity/work.

If I saw mysql as being loosely bound between it's server and lib 
components, I'd think it was good to potential chunk into two 
packages.  I don't, obviously. 

Use conditionals exist *exactly* for user choice like this (iow you've 
got the tools already to keep it contained as one).  That's honestly 
the strongest arg I can make; the limiting factor is that you're 
stuck waiting since use dep's aren't available yet.
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Georgi Georgiev]

[-- Attachment #1: Type: text/plain, Size: 1170 bytes --]

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 other feature additions"-alike.

minimal - Install a very minimal build (disables, for example, plugins,
          fonts, most drivers, non-critical features)
vanilla - Do not add extra patches which change default behaviour

The way you understand "minimal" seems to be closer to what "vanilla" is
used for. By "feature additions" I assume that you mean "extra
functionality added by patches".

Note the subtle difference -- "minimal" disables default functionality
(provided upstream) while "vanilla" disables patched-in functionality.

Of course, there is the "server" use flag that mysql could use with
great success.

-- 
-*   Georgi Georgiev   -* "So, will the Andover party have a cash      -*
*-    chutz@gg3.net    *- bar?" "No, there's free beer." "Uh-oh,       *-
-*  +81(90)2877-8845   -* Stallman's gonna be pissed..." --            -*
*- ------------------- *- overheard at the Bazaar, 1999                *-

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Luke-Jr]

[-- Attachment #1: Type: text/plain, Size: 365 bytes --]

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 
sense.
-- 
Luke-Jr
Developer, Utopios
http://utopios.org/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Georgi Georgiev]

[-- Attachment #1: Type: text/plain, Size: 842 bytes --]

maillog: 19/08/2005-02:59:46(+0000): 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. Fine-grained control is nice, but I also like the idea of being
able to refuse all non-upstream patches that change default behaviour.
Similarly to what mutt is doing:

!vanilla? ( nntp? ( .... ) some other patches that have no useflag )

> For changing mere defaults, a "gentoo" USE flag seems like it would make 
> sense.

-- 
\    Georgi Georgiev   \  Alcoholics Anonymous is when you get to      \
 /    chutz@gg3.net     / drink under someone else's name.              /
\   +81(90)2877-8845   \                                               \

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Christian Parpart]

[-- Attachment #1: Type: text/plain, Size: 2274 bytes --]

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 other feature additions"-alike.
>
> minimal - Install a very minimal build (disables, for example, plugins,
>           fonts, most drivers, non-critical features)
> vanilla - Do not add extra patches which change default behaviour

I agree with these definitions.

however, why I was refering to the "minimal" use-flag anyway, was, because 
comment 1 in the bug-report statet, that we *do* have the "minimal" use-flag 
to achieve, what the bug-reporter was intending to get (a splitout of 
client-only libs/headers);

Extract of comment 1 in the bug:
| New ebuilds have the "minimal" use flag. This flag build the server with
| "configure --without-server" .  
| explaining better this last point. You still need to download ALL the
| package from MySQL site *BUT* only the libraries will be installed. 

They reason for why I was ever intending to ask here on -dev and why I'm CCed 
in the bug still is:
* it looks a little overbloated, when you wanna install cat/foo 
  ebuild that supports to back its data to mySQL instead of sqlite, 
  and you  *have* to install a server for that (not always); 
  this might be irrelevant for desktop machines, but the hell 
  not for servers; you can't predict, that you maintain 
  INSTALL_MASK-alike var to prevent such things being installed. 
  you (in first place) do not know what you all need to mask anyway
* a useflag (so I use and understand them) are for enabling features or
  other *extra* advantages (like kdeenablefinal or debug);
* while having not taken a look at the mysql build side, I don't 
  believe, that it would be an overhead in splitting out 
  libmysqlclient (and that's what we're finally talking about) 
  and making (for backwards compatibility and use) it a depend 
  to the already existing dev-db/mysql package;

Regards,
Christian Parpart.

-- 
 04:26:38 up 148 days, 17:34,  1 user,  load average: 0.86, 1.39, 1.97














[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]