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.62) (envelope-from ) id 1HvwrT-0005wp-16 for garchives@archives.gentoo.org; Wed, 06 Jun 2007 14:51:47 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.0/8.14.0) with SMTP id l56EnWhr030698; Wed, 6 Jun 2007 14:49:32 GMT Received: from polito.it (atena.polito.it [130.192.3.45]) by robin.gentoo.org (8.14.0/8.14.0) with ESMTP id l56EkLlR026427 for ; Wed, 6 Jun 2007 14:46:22 GMT X-ExtScanner: Niversoft's FindAttachments (free) Received: from [130.192.5.32] ([130.192.5.32] verified) by atena.polito.it (CommuniGate Pro SMTP 5.1.9) with ESMTPS id 6691977 for gentoo-dev@lists.gentoo.org; Wed, 06 Jun 2007 16:46:20 +0200 Message-ID: <4666C962.6040504@gentoo.org> Date: Wed, 06 Jun 2007 16:49:06 +0200 From: Luca Barbato User-Agent: Thunderbird 1.5.0.10 (X11/20070314) 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [PMS] new dep list (useful just for cross stuff) References: <46667D30.4040501@gentoo.org> <20070606104315.5e35f582@snowflake> In-Reply-To: <20070606104315.5e35f582@snowflake> X-Enigmail-Version: 0.94.3.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: 73db3f90-4b06-4804-8c21-fc828fa8da9b X-Archives-Hash: d05f2bcaa853250e27a20f3ce5e05873 Ciaran McCreesh wrote: > On Wed, 06 Jun 2007 11:24:00 +0200 > Luca Barbato wrote: >> PMS overlords what's your take? > > You need to start by identifying use cases. Are you discussing handling > cross compiling, Yes multilib, Ok C++ / python ABIs Aaaaaargh, ehm, should we really throw them in the mix? anyway let me see if the same rules apply: - they have to reside in a separate path if possible? - the linker must not pick wrong ones in place of the ones you want to use. - an application using a former abi must link depend on stuff from the same place but MAY use stuff from another place. - is up to the loader pick the right paths on execution - the dep resolver should ignore packages built using the other C++/Python abi. The issue is more complex and I just ignored it basically because the library abi mismatch is an error that should be rectified and not something you want and no it isn't because I don't care about binary only stuff right now, it's just because looks like there is already too much meat w/out something that fits just halfway on the constraints. or all of them? Then you > need to identify what packages would need to do to handle those things. All. > Don't even think about the package manager side until you've worked out > what ebuilds would do. autotooled programs more or less are already doing the right thing, non autotools packages supporting cross development may require some additional checks to pass the right target. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list