From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1JrrfG-0002S1-4I for garchives@archives.gentoo.org; Fri, 02 May 2008 09:34:50 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 38220E05C1; Fri, 2 May 2008 09:34:48 +0000 (UTC) Received: from smtp8-g19.free.fr (smtp8-g19.free.fr [212.27.42.65]) by pigeon.gentoo.org (Postfix) with ESMTP id E5E9DE05C1 for ; Fri, 2 May 2008 09:34:47 +0000 (UTC) Received: from smtp8-g19.free.fr (localhost [127.0.0.1]) by smtp8-g19.free.fr (Postfix) with ESMTP id A9A7917F510 for ; Fri, 2 May 2008 11:34:47 +0200 (CEST) Received: from [192.168.0.13] (bne75-10-88-178-16-229.fbx.proxad.net [88.178.16.229]) by smtp8-g19.free.fr (Postfix) with ESMTP id 5F40517F58C for ; Fri, 2 May 2008 11:34:47 +0200 (CEST) Message-ID: <481ADF56.9020402@gentoo.org> Date: Fri, 02 May 2008 11:31:02 +0200 From: =?ISO-8859-1?Q?R=E9mi_Cardona?= User-Agent: Thunderbird 2.0.0.12 (X11/20080213) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] RFC: language bindings as separate packages References: <20080501150930.GA25855@nibiru.local> <481AC22E.7020908@gentoo.org> <20080502090014.GE25855@nibiru.local> In-Reply-To: <20080502090014.GE25855@nibiru.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 569acd2b-ed09-422a-94b4-511310143e3a X-Archives-Hash: 25bd47a6ec9f80bea8d3947b7308edcb Enrico Weigelt a =E9crit : > * Luca Barbato schrieb: >> Enrico Weigelt wrote: >>> My suggestion: make those language bindings being separate >>> packages. So, other packages can depend on them directly,=20 >>> instead of the current, build-breaking hack. >>> >>> I'm not advocating gentoo should do this step alone, but=20 >>> instead join in the upstream and solve it there. >> The issue is upstream related, we can workaround it using a way to=20 >> express that requirement (usedeps, checks in pkg_setup, whatever),=20 >> obviously trying to cooperate with upstream in order to get the option= al=20 >> bindings build w/out the main program would make our life simpler and=20 >> probably their as well. >> >> Partial builds are quite a problem since they are anything but reliabl= e. >=20 > ACK. These are just hacks to work around upstream's design=20 > problems. For me, working much embedded environments, those > hacks are not an option, since builds MUST be reliable > (the packages MUST work IMMEDIATELY after deployment, since > there is no chance for doing things like revdep-rebuild). >=20 > My vote is: declaring guidelines (or better: constraints) for > clean builds and then working directly within the upstream to > get it on the road. Best example on how to do that is gstreamer. All the plugins come in 3=20 tarballs but each can be built individually. Really clean. > If the upstream really blocks it, do a=20 > fork / maintain a patchline (like OSS-QM project does). >=20 > I'm already doing so with several packages. I've seen you talk about that project before but I don't feel=20 comfortable going down that road. We want to work with upstream and let=20 them know what our needs are. Maintaining patches is a lot of work and=20 forking is even more work. Even though I'm still a relatively young=20 Gentoo dev (only been here for 1.5 years), I have yet to see upstream=20 projects reject build patches that make our lives easier. Cheers, R=E9mi --=20 gentoo-dev@lists.gentoo.org mailing list