[gentoo-dev] Re: Re: [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
Ciaran McCreesh wrote: > On Mon, 08 Sep 2008 22:40:37 +0100 > Steve Long <[EMAIL PROTECTED]> 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.
Re: [gentoo-dev] Re: Re: [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
On Sun, 31 Aug 2008 03:29:16 +0100 Steve Long <[EMAIL PROTECTED]> wrote: > > Except that that's not what it's being used to mean. It's being > > used to mean "the cost of selecting this when doing dependency > > resolution cost analysis is zero", which is an entirely different > > thing. > > > So it's zero-resolution-cost now? No, the overall cost in resolution is potentially non-zero. But the cost of selecting it for an install when resolving it is zero. > Yes, that *is* different (although > I'd use free-resolve. "free" is well understood as often meaning > "zero-cost," which isn't a phrase most English-speaking people use. > It only has meaning within the PROPERTIES variable, so it's not going > to clash with anything.) free means lots of things. > > Users don't need to see it. Heck, most developers don't need to see > > it. > > > Well any dev using it will do, and I believe most of them start out as > users. Anyone reading the ebuild will see it, and the fact that it's a > well-understood term, within Gentoo at least[2], makes it easier for > the PM user-base to work with. virtual is a well-understood term that does not mean what the property being discussed will mean. > It's a cultural "people understand this already" point as opposed to a > technical make-it-as-explicit-as-we-can one. And with this 'understanding' comes lots of misconceptions about what it means. 'virtual' implies lots of things that this property does not. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: Re: [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
Ciaran McCreesh wrote: > On Sat, 30 Aug 2008 10:59:41 +0100 > Steve Long <[EMAIL PROTECTED]> wrote: >> I concur that it makes a lot of sense, fitting in exactly with the >> meaning originally given. That it means 'zero-install-cost' is >> neither here nor there imo; 'virtual' is a well understood terms for >> the same thing: an ebuild that doesn't in itself install anything. > > Except that that's not what it's being used to mean. It's being used to > mean "the cost of selecting this when doing dependency resolution cost > analysis is zero", which is an entirely different thing. > So it's zero-resolution-cost now? Yes, that *is* different (although I'd use free-resolve. "free" is well understood as often meaning "zero-cost," which isn't a phrase most English-speaking people use. It only has meaning within the PROPERTIES variable, so it's not going to clash with anything.) 'Since new-style virtuals are a type of "meta-package", I'd prefer that we introduce some type of package metadata into the EAPI that distiguishes meta-packages (those that do not install anything) from normal packages.'[1] >> It's clearly something that can be useful across the tree, and can >> apply to an ebuild as opposed to a package. Forcing a category (or a >> pkgmove which is a pita aiui) seems inelegant (and doesn't enable the >> second use-case); the property is far more appropriate, and as you >> say, 'virtual' is less confusing for a user than 'zero-install-cost', >> especially within Gentoo. > > Users don't need to see it. Heck, most developers don't need to see it. > Well any dev using it will do, and I believe most of them start out as users. Anyone reading the ebuild will see it, and the fact that it's a well-understood term, within Gentoo at least[2], makes it easier for the PM user-base to work with. It's a cultural "people understand this already" point as opposed to a technical make-it-as-explicit-as-we-can one. That it's easier to scan and type is a bonus. [1] http://bugs.gentoo.org/show_bug.cgi?id=141118#c5 (bug has previously been cited as part of the motivation for this property.) [2] Of course for a new project, one could use whichever term one felt like, since users would be expecting a divergent codebase. Heck, it might even be worth changing names of stuff just for the sake of appearing shiny (or to kill backward-compatibility, or make it harder for people to make the mental switch back. Every little helps.)
