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