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.60) (envelope-from ) id 1GR4uC-0003Du-A4 for garchives@archives.gentoo.org; Sat, 23 Sep 2006 10:38:44 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.8/8.13.6) with SMTP id k8NAbpMO023134; Sat, 23 Sep 2006 10:37:51 GMT Received: from smtp1.su.se (smtp1.su.se [130.237.162.112]) by robin.gentoo.org (8.13.8/8.13.6) with ESMTP id k8NAZxCl018699 for ; Sat, 23 Sep 2006 10:35:59 GMT Received: from localhost (localhost [127.0.0.1]) by smtp1.su.se (Postfix) with ESMTP id 1AECB740A4 for ; Sat, 23 Sep 2006 12:35:59 +0200 (CEST) Received: from smtp1.su.se ([127.0.0.1]) by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 30991-01-32 for ; Sat, 23 Sep 2006 12:35:58 +0200 (CEST) Received: from ext0.ml.kva.se (ext0.ml.kva.se [130.237.201.25]) by smtp1.su.se (Postfix) with ESMTP id 812937406E for ; Sat, 23 Sep 2006 12:35:58 +0200 (CEST) Received: from wlan42.mittag-leffler.se (wlan42.mittag-leffler.se [130.237.201.242]) by ext0.ml.kva.se (8.13.6/8.13.6) with ESMTP id k8NAZwAW023477 for ; Sat, 23 Sep 2006 12:35:58 +0200 (CEST) Subject: Re: [gentoo-dev] RFC about another *DEPEND variable From: Duncan Coutts To: gentoo-dev@lists.gentoo.org In-Reply-To: <200609230613.12769.vapier@gentoo.org> References: <45126B07.6030403@gentoo.org> <200609211111.31539.vapier@gentoo.org> <1158853263.16173.115.camel@localhost> <200609230613.12769.vapier@gentoo.org> Content-Type: text/plain Date: Sat, 23 Sep 2006 12:35:54 +0200 Message-Id: <1159007755.22846.5.camel@localhost> 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 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.665 tagged_above=-99 required=7 tests=[BAYES_00=-1.665] X-Spam-Level: X-Archives-Salt: 1df5332b-5f21-4494-990b-886dcaf6f294 X-Archives-Hash: eae005ef1b7354999cedfa2382f02ad8 On Sat, 2006-09-23 at 06:13 -0400, Mike Frysinger wrote: > On Thursday 21 September 2006 11:41, Duncan Coutts wrote: > > On Thu, 2006-09-21 at 11:11 -0400, Mike Frysinger wrote: > > > On Thursday 21 September 2006 10:56, Duncan Coutts wrote: > > > > If we do go in this direction it'd be great to be able to slot on the > > > > ABI and still have dependencies resolved correctly. For example imagine > > > > having parallel python-2.3 and 2.4 installations with some libs > > > > installed for both. Crucially, deps need to be resolved to the version > > > > of a lib with the right ABI. > > > > > > ugh, no ... we are not a binary distribution so we should not have to > > > worry about ABI baggage > > > > So we can't ever install two versions of python or ghc at once? That > > seems a shame. > > that's an issue for the python or ghc maintainers to address Yes and as ghc maintainer for Gentoo I'd love to be able to do it. It is easy to install more than one version of ghc at once as it uses versioned directories etc. The problem is that we cannot correctly resolve dependencies with the current versions of portage. Hence we cannot effectively do it. I was worried from your ABI/API comments that you meant that we should never be allowed to do it. As I said before, if we were to SLOT ghc and the various dev-haskell/* libs on the ghc version then we would run into this problem: assume dev-haskell/foo needs dev-haskell/bar supposing dev-haskell/bar was installed and sloted for ghc-6.2 now I install ghc-6.4 too now I emerge dev-haskell/foo. portage will use the existing installation of dev-haskell/bar even though it was installed for another version of ghc. Therefore the build will break (think of haskell libs of having a SONAME that is the version of ghc they were built with). What needs to happen is to install dev-haskell/bar sloted for ghc-6.4 and use that. Currently there is no way to explain these dependencies to portage. I was hoping that with this talk of tracking reverse deps and such like that we could move in a direction where this kind of dependency could be supported. Even if we can't slot on the ghc version, automatically rebuilding for the latest ghc version would be a great improvement - like the suggestion to rebuild dependent libs when the SONAME changes. Duncan -- gentoo-dev@gentoo.org mailing list