From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id F3DE21381F3 for ; Fri, 30 Nov 2012 07:37:00 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1C14321C004; Fri, 30 Nov 2012 07:36:51 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 5FC7DE0138 for ; Fri, 30 Nov 2012 07:36:12 +0000 (UTC) Received: from leo.local (ip-62-143-185-252.unitymediagroup.de [62.143.185.252]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jlec) by smtp.gentoo.org (Postfix) with ESMTPSA id 055E033D976; Fri, 30 Nov 2012 07:36:10 +0000 (UTC) Message-ID: <50B861E8.9040209@gentoo.org> Date: Fri, 30 Nov 2012 08:36:08 +0100 From: Justin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 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] Re: RFC: new eclass - pkgconfig.eclass References: <50B686DA.6000402@gentoo.org> <50B76022.2090007@gentoo.org> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig45A6F04E8988E18B212A24AC" X-Archives-Salt: 3e32340c-5008-41ec-9732-583515b22696 X-Archives-Hash: 9a1c756af0357d5409762bb396650267 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig45A6F04E8988E18B212A24AC Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 30.11.2012 05:37, Duncan wrote: > hasufell posted on Thu, 29 Nov 2012 14:16:18 +0100 as excerpted: >=20 >> again, even if there are corner cases which cannot be dealt with in a >> different way... >> >> having an eclass function like the mentioned one is bad, cause it >> suggests that this is a way to fix things. It's not. Application >> developers running gentoo might think "oh great, there is a pkgconfig >> file for this, so I can use it in my Makefile". Then a Fedora packager= >> comes across this package and realizes a compile failure until he >> notices the build system is calling for a pkgconfig file that cannot b= e >> found anywhere. So he contacts this developer and asks which distro he= >> is using. >> >> This already happened for me multiple times and the answers was >> "debian". >> >> All this sounds like a very dirty workaround and if you need it, then = do >> it, but _don't_ create an eclass, cause it's not a good thing to >> standardize. >> These files should _not_ be distro-dependant. Try to find other >> solutions. >> >> -1 for this eclass >=20 > Suggestion/question for Justin, Mike (Spanky), and others. >=20 > Assuming people eventually agree that this is a special case, which I'm= =20 > beginning to think it might be after reading Justin's arguments, tho I = > recognize that's not a settled case yet... >=20 > The glibc ebuilds use glibc-specific eblits. This keeps the glibc- > specific common code out of the ebuilds (and out of more general purpos= e=20 > eclasses) and in the files dir. >=20 > Obviously that specific solution won't work for the multiple blas/ > whatever packages, since it's single-package/multi-version specific, bu= t=20 > is there some variant of it that could work, keeping the code out of=20 > eclasses where the not-for-general-purpose solution might be mistakenly= =20 > thought to be general purpose and get used as such, while still allowin= g=20 > a common to the various *blas/whatever packages solution? >=20 > The best I can come up with is eblits, thus keeping it out of the=20 > individual ebuilds, but forcing the eblits to be copied to all the=20 > different implementations individually. Still, that'd save a bit of co= de=20 > between multiple versions of the same package, and a script could be=20 > setup that updates all the eblits in the various packages in one go, so= =20 > it'd be a bit better than having to do it per ebuild. >=20 > But perhaps someone else can improve on that idea... >=20 > Another alternative might be an eclass, but name it something like blas= - > utils or some such, not pkgconfig, thus discouraging inappropriate use,= =20 > and put in strict warnings and possibly repoman checks, so that only a = > specific list of packages are allowed to use it. That list could then = be=20 > controlled by either the science or QA teams as thought appropriate, th= us=20 > strictly limiting the spread of this ordinarily inappropriate practice.= >=20 Thanks for making thoughts about this issue. Meanwhile I talked back to my team lead and he told me that the final solution will be without pc files. This is work in progress, but it will be pc file free and alos not bypassing the buildsystem in anyway. But lets wait. Thanks, Justin --------------enig45A6F04E8988E18B212A24AC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEAREKAAYFAlC4YegACgkQgAnW8HDreRZrSwCguBAOSDj9+Rn9aBBXOeXPKkBB q58An3WrCjfPZPwyYtZeQrIHj2SOs4jk =MNLx -----END PGP SIGNATURE----- --------------enig45A6F04E8988E18B212A24AC--