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 1GI7L8-0001RZ-7M for garchives@archives.gentoo.org; Tue, 29 Aug 2006 17:25:30 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.7/8.13.6) with SMTP id k7THOGrM009409; Tue, 29 Aug 2006 17:24:16 GMT Received: from egr.msu.edu (jeeves.egr.msu.edu [35.9.37.127]) by robin.gentoo.org (8.13.7/8.13.6) with ESMTP id k7THJm8U020704 for ; Tue, 29 Aug 2006 17:19:48 GMT 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 k7THJiVN020010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 29 Aug 2006 13:19:48 -0400 (EDT) Message-ID: <44F469C6.2000602@gentoo.org> Date: Tue, 29 Aug 2006 12:22:30 -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 Subject: Re: [gentoo-dev] Portage Sets References: <44F42BB7.4010005@gentoo.org> <20060829162220.7cf8e735@c1358217.kevquinn.com> In-Reply-To: <20060829162220.7cf8e735@c1358217.kevquinn.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: c28e8ba7-5909-4e5d-8d1e-52beb285f976 X-Archives-Hash: a7656da67a55f0a6224b56645ae0f660 Kevin F. Quinn wrote: > On Tue, 29 Aug 2006 07:57:43 -0400 > Alec Warner wrote: > >> So I have implemented merging of sets (more or less) in a local >> portage branch. > > Could you elaborate how the implementation of sets would differ from: > > # emerge $(cat /var/lib/portage/myset) > > where /var/lib/portage/myset is a file containing a list of atoms? > That would help in thinking what the behaviour could be. > > I'm thinking that perhaps you do everything up to but not including > qmerge for all packages then do the qmerge phase for the set in one go, > provided they all got to install ok. It might be useful to try to move > all actions that might fail during qmerge to the end of the install > phase (I'm thinking things like collision-detection, qa checks), so > that the only reason qmerge on the set would fail is lack of disk space. > one word, no ;) This is designed (for now) to be rather non-intrusive. Here you are talking about major changes with code and behavior. At this point you could implement all of that for any number of packages (not just sets). > Obviously that's simplifying somewhat - if there are build-time DEPEND > relationships between elements of the set, the set has to be broken > down into sub-sets that don't have such internal dependencies. However > I can't think of much else you would do with sets that the $(cat > ) approach doesn't already supply. Alternatively you could > require that sets must not have such internal dependencies. Dynamic sets (World,All,GLSA,System), these are not 'static' in the sense of normal files. > >> 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. > > For the initial merge case then an error before anything is merged is > good. For an upgrade merge, a warning would be more appropriate > (perhaps becoming an error with FEATURES=stricter or similar). > >> Other use cases for sets would be appreciated, as far as behavior. It >> would probably be best to provide some sort of switch. > > The most obvious use is to have a related group of packages that may > otherwise include a virtual, making the choice of that virtual explicit > (like your cron example above). > > Other sets would be simply groups of packages that make functional > sense together, where perhaps one package might make little sense > without others in the set. For example: > > sylpheed-kev = ( sylpheed-claws sylpheed-claws-mailmbox \ > sylpheed-claws-smime sylpheed-claws-rssyl sylpheed-claws-smime \ > sylpheed-claws-vcalendar) > > toolchain4 = ( \ > ~sys-devel/gcc-4.1.1 \ > ~sys-devel/binutils-2.16.1 \ > ~sys-libs/glibc-2.4 ) > > Are you considering allowing sets to contain other sets? Then world > would contain the names of sets, not just CPs. At this point, no. > >> Unmerging sets is also a fun one, I'm not sure if it's entirely >> appropriate yet. > > Would it do anything more than: > > # emerge -C $(cat /var/lib/portage/myset) > > Perhaps it would unmerge any packages merged as dependencies of the > set that are no longer dependencies of anything else currently > installed - but I think that's better handled separately. I don't want to differ from normal portage behavior in this regard. When portage can do this, sets should as well, if portage doesn't for normal packages, I don't want to special case sets. > > Ah; it occurs to me that unmerging a set should only unmerge elements > of the set that are not part of any other installed set (including > world). So behaviour is less like 'emerge $(cat )' and more like > emerge sets/ where /set/set-V.ebuild is like a meta-ebuild. > This is an interseting idea. But then not all sets are equal; world, system, and the "All" set change fairly often. Plus everything installed is in "All" so you would want to ignore that set, as well as probably the world set. -- gentoo-dev@gentoo.org mailing list