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 1GI3Bc-0006lI-96 for garchives@archives.gentoo.org; Tue, 29 Aug 2006 12:59:24 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.7/8.13.6) with SMTP id k7TCw2Mh007938; Tue, 29 Aug 2006 12:58:02 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by robin.gentoo.org (8.13.7/8.13.6) with ESMTP id k7TCsxbW016708; Tue, 29 Aug 2006 12:55:00 GMT Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id DF23164513; Tue, 29 Aug 2006 12:54:58 +0000 (UTC) Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18367-11; Tue, 29 Aug 2006 12:54:57 +0000 (UTC) Received: from egr.msu.edu (jeeves.egr.msu.edu [35.9.37.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id D38D5642E6; Tue, 29 Aug 2006 12:54:56 +0000 (UTC) Received: from [35.9.129.93] (torx [35.9.129.93]) (authenticated bits=0) by egr.msu.edu (8.13.7/8.13.4) with ESMTP id k7TCsupT012520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Aug 2006 08:54:56 -0400 (EDT) Message-ID: <44F42BB7.4010005@gentoo.org> Date: Tue, 29 Aug 2006 07:57:43 -0400 From: Alec Warner Organization: Gentoo User-Agent: Thunderbird 1.5.0.5 (X11/20060815) 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, gentoo-portage-dev@lists.gentoo.org Subject: [gentoo-dev] Portage Sets Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Status: No, score=-2.471 required=5.5 tests=[AWL=0.128, BAYES_00=-2.599] X-Spam-Score: -2.471 X-Spam-Level: X-Archives-Salt: ad7f7553-d4df-42d0-b998-e138fe66a767 X-Archives-Hash: bda784d5a1accc2a7822b9fd65c63601 So I have implemented merging of sets (more or less) in a local portage branch. However there are some use cases for which the appopriate action is ambiguous. Use Case #1: Set1 = { postfix, gentoolkit, lsof, bind-utils, vixie-cron } A set of standard tools to be on a machine. Assume a new install (ie none of the packages in Set1 are installed). Is it an error if one of the packages in the set is masked or unavailable? In this case I would say yes; if you instead just skip the masked package (say postfix in this case because it's convenient ) vixie-cron will pull ssmtp instead of postfix. Of course this will also occur if postfix is after vixie-cron in the set; but for our purposes we will assume the administrator put them in this order such that postfix will get pulled in. One could also say that the user should have used emerge -pv set1 and noticed that ssmtp is being pulled in instead of postfix. Use Case #2: Set1 = cat /var/lib/portage/world (the world set) Assume the world file has 100 packages in it, two which are masked, and three of which there are no ebuilds in the tree for. If missing packages cause an error (which in use case 1 they should imho) then the user cannot update world without unmasking things properly. The packages for which ebuilds are missing in the tree is in fact a portage bug(I think), and will probably need to be fixed. Other use cases for sets would be appreciated, as far as behavior. It would probably be best to provide some sort of switch. Unmerging sets is also a fun one, I'm not sure if it's entirely appropriate yet. -- gentoo-dev@gentoo.org mailing list