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

[Brian Harring <ferringb@gentoo.org>]

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

On Fri, Aug 19, 2005 at 05:30:42AM +0200, Christian Parpart wrote:
> On Thursday 18 August 2005 17:44, Chris Gianelloni wrote:
> > On Thu, 2005-08-18 at 10:17 -0500, Brian Harring wrote:
> > > 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.
> 
> minimize the duplication by a mysql eclass, just like we do for apache e.g. 
> (and lots of others) that prevent us from code duplication.

Point was you would have to inspect each release to ensure it still 
fits.  If upstream does this for you, it's not any more of an issue 
then normal QA.
Yes this is being anal (re: the verification), but it's proper QA ultimately.

> > I'd see no problem with this in mysql, if, for example, mysql's Makefile
> > had a "make libmysqlclient" target.  In that case, I would make it a
> > separate package. 
> 
> Having a look at the already provided libmysqlclient ebuild [1] it obviousely 
> (and for our luck) looks like upstream supports this installation types.
Multiple configure/builds required- also is worth verifying that 
building the client/server against the lib does just that, uses 
existing on disk lib rather then rebuilding.

> Why? What package would depend on the server in particular? If the user wants 
> the server to be run on localhost, than he would just have to add it to his 
> emerge args as well. I see no problems there - instead: it would be a great 
> enheancement. (IMO)
> 
> > All in all, I think it isn't worth even attempting at this time.
> read above. do you still think so? If so, why?
Increased configuration run time per upgrades, two packages two 
maintain; why is that an issue?
1) dev-db/mysql must dep on the matching lib version.  $PV address 
   this, mostly.
2) 2 packages to handle in p.mask and for doing keywording changes
3) 2 packages to handle at the user side of things for 
   keywording/masking.

Real strong points I'm sure; key thing about all of this is that it's 
increased A) work, B) manual steps required (read: points of screwup).  
All of the args come down to that, extra complexity/work.

If I saw mysql as being loosely bound between it's server and lib 
components, I'd think it was good to potential chunk into two 
packages.  I don't, obviously. 

Use conditionals exist *exactly* for user choice like this (iow you've 
got the tools already to keep it contained as one).  That's honestly 
the strongest arg I can make; the limiting factor is that you're 
stuck waiting since use dep's aren't available yet.
~harring

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