Hi,
Robin H. Johnson schrieb:
On Sat, Mar 10, 2007 at 12:56:51AM +0100, Thomas R?sner wrote:
I can understand that rationale for the client part, but which packages
would depend on the server part of e.g. MySQL if they could?
And building the server part to get the small client lib is a larger
PITA than building the client lib to get the server, no?
In other words: this is a sound argument against the client use flag,
but I don't think it's quite as convincing regarding the server flag,
which is more important IMHO.
Btw, I agree that the best thing to do would be to prompt upstream to
split those packages (where it makes sense), which is the preferred way
to handle this here (at least I read this somewhere, does it still
apply?), but does anybody do that actually? To stay with the MySQL
example, did anyone try to suggest to MySQL AB that seperate releases
for the client part* would be nice?
It depends hugely on the structure of the code-base. In MySQL for
example, if you wanted to build only the server, you'd still need a big
hunk of the shared code (it's one set of code, that is compiled in two
different ways, once for the client, and once for the server), and
building the server actually requires building the client anyway (plus
the proper shared libs) thus splitting out the source for lib, client,
server does not make sense.
Yes and no. The same applies to Postgres, and still they provide the
libs in an extra package. It just makes sense, how much of that 20M
mysql tarball is used by the client? It's like you'd have to dl apache
(four times) to get wget.
*investigates* Hm, perhaps the client does more than I thought it does,
on one sys here it's a 1.5M lib.
One of the other arguments I have against the split, and it applies to
both CVS and MySQL - is that if you don't build the server, you cannot
use src_test.
I'd guess those with -server would be cool about that.
Regards,
Thomas
--
[email protected] mailing list
