Re: [gentoo-dev] Re: [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
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. 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. 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. 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. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
Joe Peterson wrote: > Ciaran McCreesh wrote: >> Except it doesn't. A virtual ebuild: >> >> * installs nothing >> * does nothing > > I'd say that virtual does indeed do something: it pulls in other packages. > >> * 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? >> The property proposed corresponds to only the last of these. > > Still, the term "virtual" fits the spirit of the idea well. > Indeed, and it is well-understood.
Re: [gentoo-dev] Re: [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
On Tue, 26 Aug 2008 14:20:07 + (UTC) Duncan <[EMAIL PROTECTED]> wrote: > I therefore believe I like just moving them all to a *virtual*/ > category better, thus obviating the need for that particular property > in the first place. I strongly belive that it's a horrible idea to add special meanings to certain (hardcoded) category names in the package manager. Technically, names (including categories) should only be used as identifiers, not as classifiers. Marius
[gentoo-dev] Re: [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
Joe Peterson <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Sun, 31 Aug 2008 13:10:58 -0600: > Ciaran McCreesh wrote: >> Users don't need to see it. > > I cannot quite agree on that point. Given that Gentoo is a distro that > appeals to the more technically-oriented users, I personally believe > that what we expose as ebuild syntax is actually exposed to many users > fairly profoundly. Indeed. Ciaran himself is a user, now, tho a dev for other projects. Of course, I'm a user too. Both of us care (tho I'm sure he cares more than I do) about virtual and need to see it, But I think less technical user (even "luser" in some cases) is how he tends to use the word. The are certainly there, but that has never really been Gentoo's focus, and we don't expect users to need their hands held. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Re: [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
Ciaran McCreesh wrote: > Users don't need to see it. I cannot quite agree on that point. Given that Gentoo is a distro that appeals to the more technically-oriented users, I personally believe that what we expose as ebuild syntax is actually exposed to many users fairly profoundly. -Joe
Re: [gentoo-dev] Re: [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
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. > 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. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
Duncan wrote: > Ciaran McCreesh <[EMAIL PROTECTED]> posted > [EMAIL PROTECTED], excerpted below, on Tue, 26 Aug > 2008 14:20:44 +0100: > >> On Tue, 26 Aug 2008 06:39:38 + (UTC) Duncan <[EMAIL PROTECTED]> >> wrote: >>> But I think virtual works just fine for kde-base/kde, too, if one >>> simply reads it literally -- it's a virtual package in that it doesn't >>> install anything itself, even if it's a meta-package [...] >> >> So what does 'virtual' actually mean then, and how is it related to the >> defined behaviour of this property? > > I'm unsure of whether that was intended to be a rhetorical question or > not, so taking it literally... > Yeah, I think the original mail outlined the meaning quite explicitly, although this is good, perhaps for user documentation: > Opposite of real or physical. > > > So a virtual package would have the essence and effects of a real one > (dependencies and the like) but not be "real" in some way (here, zero- > install-cost, or more correctly, only the install cost of the > dependencies). > > More directly, a package that doesn't actually install anything itself, > only having dependencies that ensure other packages are installed. > > In original Gentoo usage, virtual packages didn't have ebuilds at all, > but referred to dependencies that several different packages could > provide, with the the profile generally specifying a default. Now many > of them have ebuilds, but the general idea of not installing anything > directly themselves, only thru dependencies, remains. This is equally > true of the original no-ebuild virtuals, those ebuilds in the virtual/ > categories, and various meta-packages such as kde and kde-meta. Thus, > they fit the broader defintion of "virtual" in a literal sense, > regardless of where they are located in the category tree. > 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. That kde and kde-meta are changing doesn't matter to the general suitability of the property for other meta ebuilds, although it'll be interesting to see if sets become the new method. Also, as outlined wrt live-cvs, specialisation of the base property is envisaged. > I therefore believe I like just moving them all to a *virtual*/ category > better, thus obviating the need for that particular property in the first > place. > Yeuch ;) I agree with Zac on this aspect: > existence of > meta-packages in the "java-virtuals" category [5], among others, > makes it useful to introduce the "virtual" property as a means to > identify these ebuilds. Note that some packages, such as x11-libs/qt > [6], exhibit this property for some versions and not others. So, in > some cases it may be useful to be able to specify the "virtual" > property separately for different ebuild versions. 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. PROPERTIES seems like it's going to be a very handy variable.
Re: [gentoo-dev] Re: [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zac Medico wrote: > Michal Kurgan wrote: >> On Tue, 26 Aug 2008 18:49:12 -0700 >> Zac Medico <[EMAIL PROTECTED]> wrote: > >>> The PROPERTIES approach still seems a lot simpler and practical to >>> me. It seems to me that the approach involving categories introduces >>> needless complexity without bringing any really useful benefits. >> Could you elaborate on this categories complexity? I think that the idea is >> to >> just use already available categories, not implementing additional PROPERTY >> for this functionality. > > > Forcing a relationship with the category name seems more complex and > less flexible than simply having the ability to define > PROPERTIES=virtual in any given ebuild. Let me explain a bit more in case it's not clear. By forcing a relationship between the category and some other property, and removing the flexibility that would exist had this relationship not been forced, you end up having to add the additional complexity of package splits in order to achieve what could have otherwise been accomplished without any package splits. - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAki01awACgkQ/ejvha5XGaMy6wCg3VMSZr4KyARF2RNyC5OSwxky yvEAn2lR8XOmBBqWC23sl4BZMST/VNcI =7oU2 -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Duncan and others wrote: | | Moves as for kde/kde-meta might be an issue, You can leave kde meta packages out of this discussion as our plan is to move to sets. We're going to have sets for 4.1* and plan to completely drop meta packages for 4.2. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / SPARC / KDE -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAki0z0UACgkQcAWygvVEyALJcgCcDcrM/cFW60ewFLpoTFxIdVrr /AoAnAzBGukbmxOpfPai7bPI5BlCiJY1 =Lui3 -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michal Kurgan wrote: > On Tue, 26 Aug 2008 18:49:12 -0700 > Zac Medico <[EMAIL PROTECTED]> wrote: > >> The PROPERTIES approach still seems a lot simpler and practical to >> me. It seems to me that the approach involving categories introduces >> needless complexity without bringing any really useful benefits. > > Could you elaborate on this categories complexity? I think that the idea is to > just use already available categories, not implementing additional PROPERTY > for this functionality. > Forcing a relationship with the category name seems more complex and less flexible than simply having the ability to define PROPERTIES=virtual in any given ebuild. - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAki0xxMACgkQ/ejvha5XGaOI1QCgz9yfDUaAH+KnpbhrXtl5qPSn sccAn0KTXUPhw54KIBIk6soFHNNEkOHB =xQQ5 -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
On Tue, 26 Aug 2008 18:49:12 -0700 Zac Medico <[EMAIL PROTECTED]> wrote: > The PROPERTIES approach still seems a lot simpler and practical to > me. It seems to me that the approach involving categories introduces > needless complexity without bringing any really useful benefits. Could you elaborate on this categories complexity? I think that the idea is to just use already available categories, not implementing additional PROPERTY for this functionality. -- Michal Kurgan http://dev.gentoo.org/~moloh
Re: [gentoo-dev] Re: [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Duncan wrote: > Zac Medico <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], > excerpted below, on Tue, 26 Aug 2008 10:44:22 -0700: > >> Duncan wrote: >>> I therefore believe I like just moving them all to a *virtual*/ >>> category better, thus obviating the need for that particular property >>> in the first place. >> This has been suggested elsewhere in the thread [1] but I think the the >> PROPERTIES approach will be more flexible and practical for the reasons >> that I've already stated. >> >> [1] >> http://archives.gentoo.org/gentoo-dev/ > msg_65636255c9d284e51898e826cae09ffd.xml > > Maybe it's just 'cause I'm not a dev, but I don't see the reasons you > state there as a problem. I specifically addressed the java-virtuals > category by suggesting that the trigger could be on "virtual" in the > category, not on the single category "virtual", so java-virtuals would be > included as would any other *virtual* category, and the java folks > wouldn't have to move it after all. > > Moves as for kde/kde-meta might be an issue, but I don't believe any more > so than any other package move, and since they're "virtual", possibly > less so. The splits, as for qt, might be more confusing, but it's a > one-time split either now or (for future packages) whenever they go > virtual, at which point there's a lot of work going into them anyway. > >>From my perspective, that's not significant additional cost, at least > compared to the cost associated with the PROPERTIES=virtual in the first > place. Given the advantages, including the clarity of having the virtual > property out where all can see it in the category name itself, I think > it's worth the relatively small additional cost. > > That said, it'd be nice, and to me, worth the cost, particularly as > compared to the cost of implementing a new property anyway, but since I'm > not the one implementing it (in either the PM or the packages), feel free > to override that opinion. > > There's also conceivably some times when a virtual/pkg_name might not be > a proper fit regardless of the property, making the category proposal > somewhat less flexible. I can't think of anywhere that such might be the > case, but that doesn't mean there aren't such cases. But I still believe > the benefit of having the property out there for all to see more valuable > than any potentially lost flexibility. > The PROPERTIES approach still seems a lot simpler and practical to me. It seems to me that the approach involving categories introduces needless complexity without bringing any really useful benefits. - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAki0spcACgkQ/ejvha5XGaOTygCg0phbwIFENXHBKyKryAMkgQwo RJwAoOdcjRUJAmnPK/RTBV5S0REVaYhx =QzgD -END PGP SIGNATURE-
[gentoo-dev] Re: [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
Zac Medico <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Tue, 26 Aug 2008 10:44:22 -0700: > Duncan wrote: >> I therefore believe I like just moving them all to a *virtual*/ >> category better, thus obviating the need for that particular property >> in the first place. > > This has been suggested elsewhere in the thread [1] but I think the the > PROPERTIES approach will be more flexible and practical for the reasons > that I've already stated. > > [1] > http://archives.gentoo.org/gentoo-dev/ msg_65636255c9d284e51898e826cae09ffd.xml Maybe it's just 'cause I'm not a dev, but I don't see the reasons you state there as a problem. I specifically addressed the java-virtuals category by suggesting that the trigger could be on "virtual" in the category, not on the single category "virtual", so java-virtuals would be included as would any other *virtual* category, and the java folks wouldn't have to move it after all. Moves as for kde/kde-meta might be an issue, but I don't believe any more so than any other package move, and since they're "virtual", possibly less so. The splits, as for qt, might be more confusing, but it's a one-time split either now or (for future packages) whenever they go virtual, at which point there's a lot of work going into them anyway. >From my perspective, that's not significant additional cost, at least compared to the cost associated with the PROPERTIES=virtual in the first place. Given the advantages, including the clarity of having the virtual property out where all can see it in the category name itself, I think it's worth the relatively small additional cost. That said, it'd be nice, and to me, worth the cost, particularly as compared to the cost of implementing a new property anyway, but since I'm not the one implementing it (in either the PM or the packages), feel free to override that opinion. There's also conceivably some times when a virtual/pkg_name might not be a proper fit regardless of the property, making the category proposal somewhat less flexible. I can't think of anywhere that such might be the case, but that doesn't mean there aren't such cases. But I still believe the benefit of having the property out there for all to see more valuable than any potentially lost flexibility. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Re: [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Duncan wrote: > I therefore believe I like just moving them all to a *virtual*/ category > better, thus obviating the need for that particular property in the first > place. This has been suggested elsewhere in the thread [1] but I think the the PROPERTIES approach will be more flexible and practical for the reasons that I've already stated. [1] http://archives.gentoo.org/gentoo-dev/msg_65636255c9d284e51898e826cae09ffd.xml - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAki0QPEACgkQ/ejvha5XGaPtJgCdFTpDzQfSo6zARHSje8b+h7I7 OAAAnjzo8SdYaeZ7Cmqnj+5xUSHlU7i+ =Gj7B -END PGP SIGNATURE-
[gentoo-dev] Re: [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
Ciaran McCreesh <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Tue, 26 Aug 2008 14:20:44 +0100: > On Tue, 26 Aug 2008 06:39:38 + (UTC) Duncan <[EMAIL PROTECTED]> > wrote: >> But I think virtual works just fine for kde-base/kde, too, if one >> simply reads it literally -- it's a virtual package in that it doesn't >> install anything itself, even if it's a meta-package [...] > > So what does 'virtual' actually mean then, and how is it related to the > defined behaviour of this property? I'm unsure of whether that was intended to be a rhetorical question or not, so taking it literally... According to kdict/WordNet: 2: being such in essence or effect though not in actual fact Extending that to the technical/computing realm, again kdict, this time FOLDOC and Jargon file: (Via the technical term virtual memory, probably from the term "virtual image" in optics) 1. Common alternative to logical; often used to refer to the artificial objects (like addressable virtual memory larger than physical memory) created by a computer system to help the system control access to shared resources. 2. Simulated; performing the functions of something that isn't really there. An imaginative child's doll may be a virtual playmate. Opposite of real or physical. So a virtual package would have the essence and effects of a real one (dependencies and the like) but not be "real" in some way (here, zero- install-cost, or more correctly, only the install cost of the dependencies). More directly, a package that doesn't actually install anything itself, only having dependencies that ensure other packages are installed. In original Gentoo usage, virtual packages didn't have ebuilds at all, but referred to dependencies that several different packages could provide, with the the profile generally specifying a default. Now many of them have ebuilds, but the general idea of not installing anything directly themselves, only thru dependencies, remains. This is equally true of the original no-ebuild virtuals, those ebuilds in the virtual/ categories, and various meta-packages such as kde and kde-meta. Thus, they fit the broader defintion of "virtual" in a literal sense, regardless of where they are located in the category tree. However, I like the idea someone else proposed as well. Move all these packages into the virtual category. That could of course be expanded to include java-virtuals if desired, since virtual is still part of the category name. Either as a single category or as anything with "virtual" in the category, this would make things easier for both the package manager (making the property unnecessary) and the user, who would then know on sight (in the tab-completion and in --pretend/ask as well as various $PM messages) which packages were virtual. Putting all virtual packages in the virtual category/ies would certainly simplify the task of explaining to confused users why removing say kde- base/games wanted to remove virtual/kde (instead of kde-base/kde), but wouldn't directly remove kdebase (tho emerge --depclean would then want to do so, until the user did an emerge --no-replace kdebase, at least), to use an example I saw in a different context recently. I therefore believe I like just moving them all to a *virtual*/ category better, thus obviating the need for that particular property in the first place. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Re: [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
On Tue, 26 Aug 2008 06:39:38 + (UTC) Duncan <[EMAIL PROTECTED]> wrote: > But I think virtual works just fine for kde-base/kde, too, if one > simply reads it literally -- it's a virtual package in that it > doesn't install anything itself, even if it's a meta-package rather > than having the meaning of the old-style virtual, that of selecting > one of many providers. So the only problem with virtual is the > narrower old meaning. Whether that's a big enough problem to worry > about is of course debatable, but I don't personally believe it is, > and find it every bit as clear and actually much less confusing than > zero-install-cost. So what does 'virtual' actually mean then, and how is it related to the defined behaviour of this property? -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
David Leverton <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Mon, 25 Aug 2008 21:03:26 +0100: > On Monday 25 August 2008 20:36:34 Zac Medico wrote: >> > Zac Medico <[EMAIL PROTECTED]> wrote: >> >> Looking at the dependencies of kde-base/kde, it seems like it would >> >> be eligible to exhibit the "virtual" property. >> >> I'm inclined toward "virtual" since it's more brief and I think it >> might strike a chord with more people because of their familiarity with >> the "virtual" category and old-style PROVIDE virtuals. We'll have to >> see what others have to say. > > kde-base/kde isn't like a new- or old-style virtual. If you want it to > be used for metapackages and things too, calling it "virtual" would be > confusing. Well, we could all it meta, but then we'd have the opposite problem. So what about meta-virt, or similar? But I think virtual works just fine for kde-base/kde, too, if one simply reads it literally -- it's a virtual package in that it doesn't install anything itself, even if it's a meta-package rather than having the meaning of the old-style virtual, that of selecting one of many providers. So the only problem with virtual is the narrower old meaning. Whether that's a big enough problem to worry about is of course debatable, but I don't personally believe it is, and find it every bit as clear and actually much less confusing than zero-install-cost. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
