From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.3/8.13.3) with ESMTP id j26I9RKJ010497 for ; Sun, 6 Mar 2005 18:09:28 GMT Received: from ppsw-6.csi.cam.ac.uk ([131.111.8.136]) by smtp.gentoo.org with esmtp (Exim 4.42) id 1D80By-00086U-Cb for gentoo-dev@robin.gentoo.org; Sun, 06 Mar 2005 18:09:26 +0000 Received: from spb42.christs.cam.ac.uk ([131.111.233.172]:47516) by ppsw-6.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:465) with esmtpsa (PLAIN:spb42) (SSLv3:RC4-MD5:128) id 1D80Bx-0001QD-Jq (Exim 4.44) for gentoo-dev@gentoo.org (return-path ); Sun, 06 Mar 2005 18:09:25 +0000 Subject: Re: [gentoo-dev] GLEP ??: Metapackages From: Stephen Bennett To: gentoo-dev@robin.gentoo.org In-Reply-To: <200503061940.06006.danarmak@gentoo.org> References: <1109715352.3788.42.camel@localhost> <200503061940.06006.danarmak@gentoo.org> Content-Type: text/plain Date: Sun, 06 Mar 2005 18:12:17 +0000 Message-Id: <1110132737.9219.10.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@gentoo.org Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 Content-Transfer-Encoding: 7bit Sender: spb42@hermes.cam.ac.uk X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Archives-Salt: f54fa053-6940-414f-b44d-5d7435ee4d3f X-Archives-Hash: 23a692d470722c2f03425c829dc29b95 On Sun, 2005-03-06 at 19:40 +0200, Dan Armak wrote: > It's a cool idea. What's missing in the proto-GLEP is an explanation of why > you can't do this with a normal ebuild (that doesn't install any files), and > need the new concept of metapackages. The idea is that a metapackage, unlike a normal ebuild, doesn't exist in the installed package db, and its deps are always inspected when it turns up in the depgraph. That means that you avoid the situation where you merge package A, which depends on virtual/x11, and then pulls in xorg-x11. Then, for whatever reason, you unmerge xorg, and virtual/x11 is still in the vdb, so the next app you merge that deps on it will break. That was explained in the -dev thread I linked; I probably should add an explanation into the GLEP. > There's also the question of portage not checking RDEPENDs when unmerging, so > you can unmerge a dep (and things will break) but you can't unmerge a package > providing a virtual (portage will catch that). But the correct solution here, > if we're going to modify portage, is to add generic RDEPEND checking support > to emerge unmerge... Allegedly the new dep resolver that's being worked on should handle that... not sure if it'll get into the next portage release though. But agreed, it is needed, and from what I've been given to understand should handle this situation properly without too much extra effort. > Also, the GLEP says: "On a side note, this system of metapackages would > provide an implementation of 'package sets' as proposed in GLEP 21 [2]_." > > I don't see how that would happen. A package set exists to install all of a > list of packages, while a virtual/metapackage exists to install one of a list > of (often mutually exclusive) packages. These are very different goals. How > would metapackages help with sets any more than ordinary ebuilds already do? Since the metapackage has some arbitrary DEPEND string that has to be met, there's no reason why this couldn't require all packages reckoned to be part of a set, rather than one of the packages reckoned to provide a virtual. -- gentoo-dev@gentoo.org mailing list