1 |
On Sat, Mar 10, 2007 at 12:56:51AM +0100, Thomas R?sner wrote: |
2 |
> I can understand that rationale for the client part, but which packages |
3 |
> would depend on the server part of e.g. MySQL if they could? |
4 |
> And building the server part to get the small client lib is a larger |
5 |
> PITA than building the client lib to get the server, no? |
6 |
> |
7 |
> In other words: this is a sound argument against the client use flag, |
8 |
> but I don't think it's quite as convincing regarding the server flag, |
9 |
> which is more important IMHO. |
10 |
> |
11 |
> Btw, I agree that the best thing to do would be to prompt upstream to |
12 |
> split those packages (where it makes sense), which is the preferred way |
13 |
> to handle this here (at least I read this somewhere, does it still |
14 |
> apply?), but does anybody do that actually? To stay with the MySQL |
15 |
> example, did anyone try to suggest to MySQL AB that seperate releases |
16 |
> for the client part* would be nice? |
17 |
It depends hugely on the structure of the code-base. In MySQL for |
18 |
example, if you wanted to build only the server, you'd still need a big |
19 |
hunk of the shared code (it's one set of code, that is compiled in two |
20 |
different ways, once for the client, and once for the server), and |
21 |
building the server actually requires building the client anyway (plus |
22 |
the proper shared libs) thus splitting out the source for lib, client, |
23 |
server does not make sense. |
24 |
|
25 |
One of the other arguments I have against the split, and it applies to |
26 |
both CVS and MySQL - is that if you don't build the server, you cannot |
27 |
use src_test. |
28 |
|
29 |
-- |
30 |
Robin Hugh Johnson |
31 |
Gentoo Linux Developer |
32 |
E-Mail : robbat2@g.o |
33 |
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 |