1 |
On Thursday 18 August 2005 19:01, Georgi Georgiev wrote: |
2 |
> maillog: 18/08/2005-16:28:40(+0200): Christian Parpart types |
3 |
> |
4 |
> > Using the "minimal" useflag for this - IMHO - is a misuse of the idea of |
5 |
> > "minimal" semantically - as I do understand minimal in a way like "don't |
6 |
> > overbloat me with patches and other feature additions"-alike. |
7 |
> |
8 |
> minimal - Install a very minimal build (disables, for example, plugins, |
9 |
> fonts, most drivers, non-critical features) |
10 |
> vanilla - Do not add extra patches which change default behaviour |
11 |
|
12 |
I agree with these definitions. |
13 |
|
14 |
however, why I was refering to the "minimal" use-flag anyway, was, because |
15 |
comment 1 in the bug-report statet, that we *do* have the "minimal" use-flag |
16 |
to achieve, what the bug-reporter was intending to get (a splitout of |
17 |
client-only libs/headers); |
18 |
|
19 |
Extract of comment 1 in the bug: |
20 |
| New ebuilds have the "minimal" use flag. This flag build the server with |
21 |
| "configure --without-server" . |
22 |
| explaining better this last point. You still need to download ALL the |
23 |
| package from MySQL site *BUT* only the libraries will be installed. |
24 |
|
25 |
They reason for why I was ever intending to ask here on -dev and why I'm CCed |
26 |
in the bug still is: |
27 |
* it looks a little overbloated, when you wanna install cat/foo |
28 |
ebuild that supports to back its data to mySQL instead of sqlite, |
29 |
and you *have* to install a server for that (not always); |
30 |
this might be irrelevant for desktop machines, but the hell |
31 |
not for servers; you can't predict, that you maintain |
32 |
INSTALL_MASK-alike var to prevent such things being installed. |
33 |
you (in first place) do not know what you all need to mask anyway |
34 |
* a useflag (so I use and understand them) are for enabling features or |
35 |
other *extra* advantages (like kdeenablefinal or debug); |
36 |
* while having not taken a look at the mysql build side, I don't |
37 |
believe, that it would be an overhead in splitting out |
38 |
libmysqlclient (and that's what we're finally talking about) |
39 |
and making (for backwards compatibility and use) it a depend |
40 |
to the already existing dev-db/mysql package; |
41 |
|
42 |
Regards, |
43 |
Christian Parpart. |
44 |
|
45 |
-- |
46 |
04:26:38 up 148 days, 17:34, 1 user, load average: 0.86, 1.39, 1.97 |