Re: [gentoo-dev] ebuild design issue regarding some {I need the lib and api only}-DEPENDs

[Christian Parpart <trapni@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 2274 bytes --]

On Thursday 18 August 2005 19:01, Georgi Georgiev wrote:
> maillog: 18/08/2005-16:28:40(+0200): Christian Parpart types
>
> > 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.
>
> minimal - Install a very minimal build (disables, for example, plugins,
>           fonts, most drivers, non-critical features)
> vanilla - Do not add extra patches which change default behaviour

I agree with these definitions.

however, why I was refering to the "minimal" use-flag anyway, was, because 
comment 1 in the bug-report statet, that we *do* have the "minimal" use-flag 
to achieve, what the bug-reporter was intending to get (a splitout of 
client-only libs/headers);

Extract of comment 1 in the bug:
| New ebuilds have the "minimal" use flag. This flag build the server with
| "configure --without-server" .  
| explaining better this last point. You still need to download ALL the
| package from MySQL site *BUT* only the libraries will be installed. 

They reason for why I was ever intending to ask here on -dev and why I'm CCed 
in the bug still is:
* it looks a little overbloated, when you wanna install cat/foo 
  ebuild that supports to back its data to mySQL instead of sqlite, 
  and you  *have* to install a server for that (not always); 
  this might be irrelevant for desktop machines, but the hell 
  not for servers; you can't predict, that you maintain 
  INSTALL_MASK-alike var to prevent such things being installed. 
  you (in first place) do not know what you all need to mask anyway
* a useflag (so I use and understand them) are for enabling features or
  other *extra* advantages (like kdeenablefinal or debug);
* while having not taken a look at the mysql build side, I don't 
  believe, that it would be an overhead in splitting out 
  libmysqlclient (and that's what we're finally talking about) 
  and making (for backwards compatibility and use) it a depend 
  to the already existing dev-db/mysql package;

Regards,
Christian Parpart.

-- 
 04:26:38 up 148 days, 17:34,  1 user,  load average: 0.86, 1.39, 1.97














[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]