[gentoo-dev] Re: Re: [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)

[Steve Long <slong@rathaus.eclipse.co.uk>]

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.