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 <gentoo-dev+bounces-32710-garchives=archives.gentoo.org@lists.gentoo.org>)
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 <gentoo-dev@lists.gentoo.org>; 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 <gentoo-dev@lists.gentoo.org>; 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 <gentoo-dev@lists.gentoo.org>;
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 <gentoo-dev@gentoo.org>; 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 <gentoo-dev@gentoo.org>; 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 <gentoo-dev@gentoo.org>; Wed, 10 Sep 2008 01:36:24 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: gentoo-dev@lists.gentoo.org
From: Steve Long <slong@rathaus.eclipse.co.uk>
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: <ga78af$9ql$1@ger.gmane.org>
References: <48B1CC3C.2000103@gentoo.org> <20080905154427.a3c9e04b.genone@gentoo.org> <48C15278.2040601@gentoo.org> <20080905164623.5258b609@googlemail.com> <48C15560.6080508@gentoo.org> <ga46f5$4kj$1@ger.gmane.org> <20080908230718.5bcb665d@snowmobile>
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
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 <news@ger.gmane.org>
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 <slong@rathaus.eclipse.co.uk> 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.