From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1KdEdO-0002Gk-Ih for garchives@archives.gentoo.org; Wed, 10 Sep 2008 01:36:42 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id ABC30E0414; Wed, 10 Sep 2008 01:36:41 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 579F8E0414 for ; Wed, 10 Sep 2008 01:36:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 4CD7FB47C7 for ; Wed, 10 Sep 2008 01:36:40 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -1.532 X-Spam-Level: X-Spam-Status: No, score=-1.532 required=5.5 tests=[AWL=-0.001, BAYES_00=-2.599, FUZZY_VLIUM=0.001, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] 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 sv8H14EmTXx7 for ; Wed, 10 Sep 2008 01:36:34 +0000 (UTC) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 6B57DB4A47 for ; Wed, 10 Sep 2008 01:36:33 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KdEd6-0001L5-Sr for gentoo-dev@gentoo.org; Wed, 10 Sep 2008 01:36:24 +0000 Received: from 91.85.182.210 ([91.85.182.210]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 10 Sep 2008 01:36:24 +0000 Received: from slong by 91.85.182.210 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 10 Sep 2008 01:36:24 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Steve Long Subject: [gentoo-dev] Re: Re: [RFC] PROPERTIES=virtual for meta-packages (clarification of definition) Date: Wed, 10 Sep 2008 02:30:23 +0100 Message-ID: References: <48B1CC3C.2000103@gentoo.org> <20080905154427.a3c9e04b.genone@gentoo.org> <48C15278.2040601@gentoo.org> <20080905164623.5258b609@googlemail.com> <48C15560.6080508@gentoo.org> <20080908230718.5bcb665d@snowmobile> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.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-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 91.85.182.210 User-Agent: KNode/0.10.9 Sender: news X-Archives-Salt: d2c35b88-b151-4a51-9138-18875850cad7 X-Archives-Hash: 72568d489341e8c08f160d432d7118dc Ciaran McCreesh wrote: > On Mon, 08 Sep 2008 22:40:37 +0100 > Steve Long wrote: >> >> * should be treated as being very quickly installable >> >> * should be treated as having zero cost for installs >> >> >> Both of which follow from "installs nothing." Or would you disagree? > > No, they're separate properties, with different implications. > Sure I understand that there are other properties which need to be addressed, and can be in APIx, but for the classic virtual as defined, which may be extended to be considered as having the associated cost of installing its deps in pkg-selection terms, or not, the given notation suffices. > Consider, for example, a split baselayout-style package. There could be > a skeleton-filesystem-layout package that does all its work in pkg_* > functions (to avoid permission and empty directory problems that come > from installing directories via the normal methods). It would install > nothing, but should not be considered for either zero-cost property. > Well, if that package spat a load of directories onto my system I'd personally consider it as installing something, and I'd expect those directories to be listed in its contents. > Or, for the reverse: a package that merely installs a simple control > file that enables functionality in another package may well be best > considered as zero-cost for package selection. If a package depends > upon || ( big-scary/processing-package simple-little/plugin-for-foo ) > and you already have foo but not plugin-for-foo installed, the right > thing for the resolver to do would be to suggest plugin-for-foo. > Sure. > As for the quickly installable property, plugin-for-foo might not > possess it -- for example, vim plugins generally do a vim tag > regeneration upon pkg_postinst, so they're not 'quick' to install even > if all they do is provide one text file. > Great, thanks for outlining some use-cases for the split properties. If virtual turns out to need a slightly different set if and when the extended properties are brought in, that can easily be done. I don't see that there's any conflict.