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 1L0JLb-0002gJ-1E for garchives@archives.gentoo.org; Wed, 12 Nov 2008 17:17:43 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 54D0EE04DE; Wed, 12 Nov 2008 17:17:43 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 2678DE04DE for ; Wed, 12 Nov 2008 17:17:43 +0000 (UTC) Received: from 0x3ef266d2.svgnxx4.dynamic.dsl.tele.dk (0x3ef266d2.svgnxx4.dynamic.dsl.tele.dk [62.242.102.210]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id E0FDC642D7 for ; Wed, 12 Nov 2008 17:17:40 +0000 (UTC) From: Peter Alfredsen To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass Date: Wed, 12 Nov 2008 18:16:02 +0100 User-Agent: KMail/1.9.10 References: <200811091704.10291.loki_val@gentoo.org> <200811121540.50740.loki_val@gentoo.org> <491B00DB.4000901@gentoo.org> In-Reply-To: <491B00DB.4000901@gentoo.org> 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 Content-Type: multipart/signed; boundary="nextPart1826468.9rBU02DYVI"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200811121816.04870.loki_val@gentoo.org> X-Archives-Salt: 6da40aff-35e1-4632-9ada-ad859a10ff38 X-Archives-Hash: 9a8e42f9630cbf2a673ec5afde96ef40 --nextPart1826468.9rBU02DYVI Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 12 November 2008, R=E9mi Cardona wrote: > Le 12/11/2008 15:40, Peter Alfredsen a =E9crit : > > But let me point out that in most leaf-packages, removing la files > > will cause no pain, but will ensure that they do not have to be > > rebuilt if a .la-listed dependency loses its .la file. > > Mart, others and myself have already tried removing .la files to "see > what would break". And it breaks a whole lot more than we > anticipated. > > Among others, it breaks KDE3 (all of it), pulseaudio, the current > version of app-office/dia, and many more which I can't remember. That's known. So we just don't remove .la files from those. (I think pulseaudio is fixed, actually.) > In a perfect world, there would be no need for .la files. But we're > far from that perfect world. I think it's best we provide a better > solution. The problem is that in the world where we do live, .la files are needed=20 some places and a pain in the ass other places, so blanket solutions=20 will not work. > Mart had already proposed a "static-lib" USE flag. Donnie just > suggested on IRC we turn this use flag into a FEATURES flag. That's problematic. You can't turn off a FEATURES flag for individual=20 packages. See above. > I think those are much better options than just using this function > in some ebuilds. I think it would make sense to have a static-libs USE flag and couple it=20 with use of epunt_la_files where it's appropriate. FEATURES flag, no.=20 The package maintainer decides which files get installed, noone else.=20 With a FEATURES flag, we would break the whole tree and then need to fix=20 it up with RESTRICT=3Dno-static-libs for every individual ebuild where it=20 fails. Tedious and not really worth our time. By selectively doing=20 this, we can do it intelligently and over time, minimizing the=20 inconvenience to users. =2D-=20 /PA --nextPart1826468.9rBU02DYVI Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEABECAAYFAkkbD1QACgkQtEGUx4TfHiT5DgCeOoTKpJKvTWVWrbRfLGlp9+jV 0yoAni0P06Drl8x0zSwgHQelbCg0uHus =SKFn -----END PGP SIGNATURE----- --nextPart1826468.9rBU02DYVI--