1 |
On Thu, Aug 18, 2005 at 04:28:40PM +0200, Christian Parpart wrote: |
2 |
> for the general mysql ebuild, I'd propose the following splitup: |
3 |
> * dev-db/mysql-server (or myssqld) |
4 |
> * net-libs/libmysqlclient |
5 |
> * dev-db/mysql (a meta package that simply depends on both, for backward |
6 |
> compat) |
7 |
|
8 |
<snip- left for reference in following sections> |
9 |
|
10 |
> Using the "minimal" useflag for this - IMHO - is a misuse of the idea of |
11 |
> "minimal" semantically - as I do understand minimal in a way like "don't |
12 |
> overbloat me with patches and other feature additions"-alike. |
13 |
Agreed. |
14 |
|
15 |
> |
16 |
> The reason is, that some packages need to talk to (SQL )servers, but some host |
17 |
> installation do not need - or even want to (think about security policies) - |
18 |
> a local (SQL) server; |
19 |
> |
20 |
> |
21 |
> This idea of course is applicable for lots of more packages, but mysql is one |
22 |
> use case where I myself ran into; |
23 |
> |
24 |
> Do we have a general accepted gentoo policy for this? |
25 |
> |
26 |
> And... any thoughts on this subject? |
27 |
We don't split upstream packages into seperate pieces normally, and |
28 |
without a damn good reason- |
29 |
|
30 |
1) Upstream releases it combined. Yes, this can be flawed if you're |
31 |
the lucky maintainer of a package where upstream does stupid things as |
32 |
routine, but we do try to have our ports of a package as 'true' to |
33 |
upstream's original release as possible. |
34 |
|
35 |
2) ebuild maintenance will be a nightmare- every new version will |
36 |
require again walking the source to see if the lines you've drawn for |
37 |
dividing the source are still proper. |
38 |
|
39 |
3) Extension of #2, any source that's reliant on those lines you've |
40 |
drawn to chunkify a package have to be verified everytime you change |
41 |
the sets that the subpackages hold. |
42 |
|
43 |
4) (not applicable here, but a point) chunkifying a package, assuming |
44 |
you make it this far, is going to require configuration every run |
45 |
through, or you'll have to write some script to store configuration on |
46 |
the users box, and lift that (pkg-config plugin). More work, and more |
47 |
QA. |
48 |
|
49 |
5) We already provide our own 'subpackages' in a sense; an |
50 |
unconfigured ebuild can produce len(IUSE)^2 potential configurations |
51 |
of itself, each effectively a subpackage that are all labelled as that |
52 |
specific category/package-version. Yes configured is a better term |
53 |
there, but I'm trying to make a point here :P |
54 |
|
55 |
Adding a use flag to control whether or not the server chunk gets |
56 |
installed I think is a great thing, but I also think there's no way in |
57 |
hell you should attempt it now- frankly, you can't do it now because |
58 |
use dependencies aren't available in any stable portage. |
59 |
|
60 |
Yes, there is the pkg_setup die check for a use flag being no, and |
61 |
yes, anyone using that but in the most dire cases needs an atomic |
62 |
wedgie. Too much stuff depends on mysql to resort to the pkg_setup |
63 |
hack, and mysql *is* a package that is a bit server centric normally, |
64 |
meaning those who hit the pkg_setup 'surprise' hopefully will hit it |
65 |
on a test server, rather then live. |
66 |
|
67 |
People should use test servers rather then deploying changes they |
68 |
can't totally predict to a live server, but they don't, which kills |
69 |
that as an option. |
70 |
|
71 |
Short version, control what gets installed via use flags, but don't |
72 |
introduce it until use deps are available in a stable portage. |
73 |
Breaking the beast up now is short sighted since use deps are |
74 |
already implemented in the core rewrite. Yes, waiting is a pain in |
75 |
the ass, but the work to break it up and continue to indefinitely |
76 |
force subpackaging on an package isn't worth it. |
77 |
|
78 |
My opinionated 2 cents... |
79 |
~harring |