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.43) id 1DzjzR-0008FY-Lo for garchives@archives.gentoo.org; Mon, 01 Aug 2005 23:46:38 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j71NjGgK022016; Mon, 1 Aug 2005 23:45:16 GMT Received: from smtp-out3.blueyonder.co.uk (smtp-out3.blueyonder.co.uk [195.188.213.6]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j71NhKTQ007398 for ; Mon, 1 Aug 2005 23:43:20 GMT Received: from snowdrop.home ([82.41.57.20]) by smtp-out3.blueyonder.co.uk with Microsoft SMTPSVC(5.0.2195.6713); Tue, 2 Aug 2005 00:44:19 +0100 Date: Tue, 2 Aug 2005 00:43:22 +0100 From: Ciaran McCreesh To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Modular X plans Message-ID: <20050802004322.5d087f55@snowdrop.home> In-Reply-To: <42EEAEF9.9080300@egr.msu.edu> References: <42EE8C03.3040904@gentoo.org> <20050801220425.13d75e15@snowdrop.home> <42EE92BA.9070903@gentoo.org> <20050801224419.5745f1c0@snowdrop.home> <42EE99FC.7050004@gentoo.org> <20050801231112.4a77a421@snowdrop.home> <42EEAEF9.9080300@egr.msu.edu> X-Mailer: Sylpheed-Claws 1.0.5 (GTK+ 1.2.10; i686-pc-linux-gnu) 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 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Aug 2005 23:44:19.0669 (UTC) FILETIME=[EFA42050:01C596F2] X-Archives-Salt: 181ebd84-1bfe-4bd8-b8ca-e96a239766d2 X-Archives-Hash: ddc6bd6b7a23529c55f0e9c9d2322bac On Mon, 01 Aug 2005 19:23:37 -0400 Alec Warner wrote: | > Hrmmmmm. Is this going to be sanely doable by your average dev? How | > long a dep string would we be having in typical cases? How about in | > bad cases? | > | The more formal the depstring, the quicker the packages build ( | using | only needed packages instead of lumping them in one group ). This is | essentially what the DEPEND should be, just what the packages needs to | compile and run. This especially benefits embedded targets who need a | bare-bones set of libraries and nothing else. The problem is... By hard-coding a bunch of xorg packages, you're making your DEPEND *less* accurate. Most packages will build just fine with other X implementations. Mmm, but for now this is pretty much a pointless argument. We're not a real metadistribution yet :) | I think concepts are important and abstract complexity from a | packages | DEPEND. However, having the DEPEND be accurate is important as well. | This almost reeks of the USE group GLEP being applied here as well. | Setting up DEPEND-set would be great for this, although it is | difficult to imagine sets that can be shared between many packages. | eclasses are marginally decent for this right now anyway. GLEP 37 allows that, in effect. Speaking of GLEP 37... Jason -- I'm assuming that virtual-x11/ (say) would be possible? | The problem with the individual approach is if I wanted to run | XFree, | or a competing X implementation, I have to add about 200+ packages to | /etc/portage/package.provided. This is not clean at all; it's | hideous. If I add the meta-build to /etc/portage/package.provided it | just means that I am managing the meta-ebuild and it is valid to count | it as installed for dep calculation. This is not true of any of the | dependencies of the meta-ebuild however. Thats just what I remember | fro m discussion about it, so correct me if it's wrong ;) Providing a specific metapackage is a bad idea. What if a package really does depend upon xorg? Providing a specific concept would be better. Whether such a thing is implementable currently is up for debate... -- Ciaran McCreesh -- gentoo-dev@gentoo.org mailing list