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 j26HM3br006299 for ; Sun, 6 Mar 2005 17:22:03 GMT Received: from smtp1.actcom.co.il ([192.114.47.64]) by smtp.gentoo.org with esmtp (Exim 4.42) id 1D7zS5-0000Fq-O9 for gentoo-dev@robin.gentoo.org; Sun, 06 Mar 2005 17:22:02 +0000 Received: from alpha.danarmak.homelinux.net (l85-130-135-178.broadband.actcom.net.il [85.130.135.178]) by smtp1.actcom.co.il (8.13.3/8.13.3) with ESMTP id j26HLtx1030423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 6 Mar 2005 19:22:00 +0200 Received: from localhost ([127.0.0.1]) (TLS: TLSv1/SSLv3,128bits,RC4-MD5) by alpha.danarmak.homelinux.net with esmtp; Sun, 06 Mar 2005 19:40:07 +0200 id 00F78F1C.422B4077.0000469C From: Dan Armak Organization: Gentoo Technologies, Inc. To: gentoo-dev@robin.gentoo.org Subject: Re: [gentoo-dev] GLEP ??: Metapackages Date: Sun, 6 Mar 2005 19:40:02 +0200 User-Agent: KMail/1.8 References: <1109715352.3788.42.camel@localhost> In-Reply-To: <1109715352.3788.42.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 Content-Type: multipart/signed; boundary="nextPart55526871.U9No9kJ1iI"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200503061940.06006.danarmak@gentoo.org> X-Archives-Salt: bfa22023-454c-4b61-8386-2080a8a84a3d X-Archives-Hash: f4668c7fa278dab9cb014b8f1e25fdad --nextPart55526871.U9No9kJ1iI Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 02 March 2005 00:15, Stephen Bennett wrote: > As those who hang around in the mysterious realms of Portage development > may know, there's some feeling around that the current system of virtual > packages has some serious limitations. The currently-proposed > alternative (as discussed previously, notably in > http://thread.gmane.org/gmane.linux.gentoo.devel/18922), involves a > system of metapackages. These would essentially consist of a > non-installable ebuild that consists entirely of a set of dependency > information. Once the dependencies for the metapackage are satisfied, > it's considered to be installed, and packages depending on it can go > ahead and be built. It's a cool idea. What's missing in the proto-GLEP is an explanation of why= =20 you can't do this with a normal ebuild (that doesn't install any files), an= d=20 need the new concept of metapackages. The only reason I've found (IIRC it's described in the linked thread too) i= s=20 this scenario: 1. virtual/foo has DEPEND=3D"|| ( pkgA pkgB )". 2. User has pkgB-1.5 emerged. 3. User emerges package depending on >=3Dvirtual/foo-2. 4. pkgA-2.0 is pulled in, instead of upgrading pkgB to 2.0. There's also the question of portage not checking RDEPENDs when unmerging, = so=20 you can unmerge a dep (and things will break) but you can't unmerge a packa= ge=20 providing a virtual (portage will catch that). But the correct solution her= e,=20 if we're going to modify portage, is to add generic RDEPEND checking suppor= t=20 to emerge unmerge... Am I missing another reason? Regardless, the reason for this should be in t= he=20 GLEP. Also, the GLEP says: "On a side note, this system of metapackages would=20 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= =20 list of packages, while a virtual/metapackage exists to install one of a li= st=20 of (often mutually exclusive) packages. These are very different goals. How= =20 would metapackages help with sets any more than ordinary ebuilds already do? Please enlighten me if I've totally missed your point. =2D-=20 Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key =46ingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 --nextPart55526871.U9No9kJ1iI Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCK0B1UI2RQ41fiVERArYlAJ9EeJHp16qItH7eYE7VBA6n9dZ1igCfZts0 IrEOp/XZ//kdsrdu8hAGC+c= =FBMV -----END PGP SIGNATURE----- --nextPart55526871.U9No9kJ1iI-- -- gentoo-dev@gentoo.org mailing list