From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.43) id 1E5xIh-0001Uj-EZ for garchives@archives.gentoo.org; Fri, 19 Aug 2005 03:12:11 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j7J3BRee024650; Fri, 19 Aug 2005 03:11:27 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j7J39e0h002810 for ; Fri, 19 Aug 2005 03:09:40 GMT Received: from cpe-65-26-255-237.wi.res.rr.com ([65.26.255.237] helo=nightcrawler) by smtp.gentoo.org with esmtpa (Exim 4.43) id 1E5xGK-00057a-Ua for gentoo-dev@lists.gentoo.org; Fri, 19 Aug 2005 03:09:45 +0000 Date: Thu, 18 Aug 2005 22:09:14 -0500 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] ebuild design issue regarding some {I need the lib and api only}-DEPENDs Message-ID: <20050819030914.GH19947@nightcrawler> References: <200508181628.44059.trapni@gentoo.org> <20050818151731.GA19947@nightcrawler> <1124379852.21223.161.camel@cgianelloni.nuvox.net> <200508190530.46642.trapni@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mYYhpFXgKVw71fwr" Content-Disposition: inline In-Reply-To: <200508190530.46642.trapni@gentoo.org> User-Agent: Mutt/1.5.8i X-Archives-Salt: db3f8e0b-4eac-4ef2-9303-dea236d07cd3 X-Archives-Hash: b7094b2a660259a3d0ae815ab593c5e5 --mYYhpFXgKVw71fwr Content-Type: text/plain; charset=utf8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. >=20 > minimize the duplication by a mysql eclass, just like we do for apache e.= g.=20 > (and lots of others) that prevent us from code duplication. Point was you would have to inspect each release to ensure it still=20 fits. If upstream does this for you, it's not any more of an issue=20 then normal QA. Yes this is being anal (re: the verification), but it's proper QA ultimatel= y. > > 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.=20 >=20 > Having a look at the already provided libmysqlclient ebuild [1] it obviou= sely=20 > (and for our luck) looks like upstream supports this installation types. Multiple configure/builds required- also is worth verifying that=20 building the client/server against the lib does just that, uses=20 existing on disk lib rather then rebuilding. > Why? What package would depend on the server in particular? If the user w= ants=20 > the server to be run on localhost, than he would just have to add it to h= is=20 > emerge args as well. I see no problems there - instead: it would be a gre= at=20 > enheancement. (IMO) >=20 > > 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=20 maintain; why is that an issue? 1) dev-db/mysql must dep on the matching lib version. $PV address=20 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=20 keywording/masking. Real strong points I'm sure; key thing about all of this is that it's=20 increased A) work, B) manual steps required (read: points of screwup). =20 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=20 components, I'd think it was good to potential chunk into two=20 packages. I don't, obviously.=20 Use conditionals exist *exactly* for user choice like this (iow you've=20 got the tools already to keep it contained as one). That's honestly=20 the strongest arg I can make; the limiting factor is that you're=20 stuck waiting since use dep's aren't available yet. ~harring --mYYhpFXgKVw71fwr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDBU1avdBxRoA3VU0RAlcUAJ4oUXRg5kUz2s1Gi66QW4C7Hexw7QCggXKo V1Ryks2fkvWpDHumMWhowJk= =k7yc -----END PGP SIGNATURE----- --mYYhpFXgKVw71fwr-- -- gentoo-dev@gentoo.org mailing list