From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 9E1B1139694 for ; Sat, 18 Mar 2017 10:19:04 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3BAB221C188; Sat, 18 Mar 2017 10:18:56 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id E741121C0E1 for ; Sat, 18 Mar 2017 10:18:55 +0000 (UTC) Received: from localhost (dra13-4-78-234-166-189.fbx.proxad.net [78.234.166.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: aballier) by smtp.gentoo.org (Postfix) with ESMTPSA id 7E44F3415B7 for ; Sat, 18 Mar 2017 10:18:54 +0000 (UTC) Date: Sat, 18 Mar 2017 11:18:47 +0100 From: Alexis Ballier To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] Master plan for fixing elibtoolize Message-ID: <20170318111847.34b21502@gentoo.org> In-Reply-To: <1489820011.1289.1.camel@gentoo.org> References: <1489770852.1490.6.camel@gentoo.org> <20170317233836.13b5de95@symphony.aura-online.co.uk> <1489820011.1289.1.camel@gentoo.org> Organization: Gentoo X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) 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: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: ebedba61-d87b-48ce-98b0-1c649efc92ad X-Archives-Hash: a6b8ca36fb63a62b8352fe3b641b1df1 On Sat, 18 Mar 2017 07:53:31 +0100 Micha=C5=82 G=C3=B3rny wrote: > > > 3. copy elibtoolize logic to Portage, and make it apply implicitly > > > on econf [do we need to apply it elsewhere?]; disable explicit > > > libtoolize when Portage supports that. =20 > >=20 > > Related to the above point, if you make it part of econf then it > > needs to be part of PMS and that's quite a complex beast to have in > > the spec. It has been suggested twice on this list (once quite > > recently) that the script itself should put into a separate package > > for this reason. Then PMS just needs to say "install and use this > > script" without any further detail. =20 >=20 > Strictly speaking, you don't have to have it in the PMS. This can be > left purely as Portage extension, much like gnuconfig hacking is right > now. Having different portage versions or different PM behaving differently for the same ebuild and portage tree, producing different binaries, definitely defeats PMS goals. If such things do not need to be in PMS then I don't know why we even have PMS in the first place.