Re: [gentoo-dev] [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
On Sun, 24 Aug 2008 14:01:48 -0700 Zac Medico [EMAIL PROTECTED] wrote: Do the name and definition of this PROPERTIES=virtual value seem good? Would anybody like to discuss any changes to the name, definition, or both? If it's only used to indicate that the package doesn't install any files I'd suggest to use 'empty' or 'nocontents' instead. 'virtual' somehow implies that it's only applicable to packages in the 'virtual' category, which isn't the case with the given definition (as you said). Marius
Re: [gentoo-dev] [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
Marius Mauch wrote: If it's only used to indicate that the package doesn't install any files I'd suggest to use 'empty' or 'nocontents' instead. 'virtual' somehow implies that it's only applicable to packages in the 'virtual' category, which isn't the case with the given definition (as you said). I like virtual, since it really gets at the spirit of what the ebuild does. empty sounds like it does nothing at all, and nocontents sounds that way to, to me. An analogy to virtual is a virtual method in OO programming - it sits at a high level, does nothing in itself, but causes underlying methods to perform the work. -Joe
Re: [gentoo-dev] [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
On Fri, 05 Sep 2008 09:38:32 -0600 Joe Peterson [EMAIL PROTECTED] wrote: Marius Mauch wrote: If it's only used to indicate that the package doesn't install any files I'd suggest to use 'empty' or 'nocontents' instead. 'virtual' somehow implies that it's only applicable to packages in the 'virtual' category, which isn't the case with the given definition (as you said). I like virtual, since it really gets at the spirit of what the ebuild does. empty sounds like it does nothing at all, and nocontents sounds that way to, to me. Except it doesn't. A virtual ebuild: * installs nothing * does nothing * should be treated as being very quickly installable * should be treated as having zero cost for installs The property proposed corresponds to only the last of these. An analogy to virtual is a virtual method in OO programming - it sits at a high level, does nothing in itself, but causes underlying methods to perform the work. Virtual methods in OO can do lots. You're thinking 'pure virtual' or 'abstract'. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
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 The property proposed corresponds to only the last of these. Still, the term virtual fits the spirit of the idea well. Virtual methods in OO can do lots. You're thinking 'pure virtual' or 'abstract'. Yes, you are correct (pure virtual is what I was thinking). -Joe
Re: [gentoo-dev] [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
On Sun, 24 Aug 2008 14:01:48 -0700 Zac Medico [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, Since there were some questions about ambiguity in the meaning of the proposed PROPERTIES=virtual [1] value, we need to clarify it. [ ... ] Ebuilds that exhibit the virtual property commonly serve as a layer of indirection in dependencies. All of the ebuilds in the existing virtual category [4] should be eligible to define PROPERTIES=virtual. If the ebuilds in the virtual category were the only ones that exhibited this virtual property, then the information that PROPERTIES=virtual represents could simply be inferred from membership of that category. However, 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. Wouldn't it be more appropriate to just move the offending ebuilds to virtual category? e.g. virtual/qt, etc. - -- Thanks, Zac -- Michal Kurgan http://dev.gentoo.org/~moloh
Re: [gentoo-dev] [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michal Kurgan wrote: On Sun, 24 Aug 2008 14:01:48 -0700 Zac Medico [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, Since there were some questions about ambiguity in the meaning of the proposed PROPERTIES=virtual [1] value, we need to clarify it. [ ... ] Ebuilds that exhibit the virtual property commonly serve as a layer of indirection in dependencies. All of the ebuilds in the existing virtual category [4] should be eligible to define PROPERTIES=virtual. If the ebuilds in the virtual category were the only ones that exhibited this virtual property, then the information that PROPERTIES=virtual represents could simply be inferred from membership of that category. However, 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. Wouldn't it be more appropriate to just move the offending ebuilds to virtual category? e.g. virtual/qt, etc. A package move doesn't seem very practical given that the virtual property varies from one version to the next. I suppose it could be done as a split where older versions continue to exist as x11-libs/qt and newer versions exist as virtual/qt. If we take that approach then you'll have to convince the java team to combine the whole java-virtuals category [1] into the virtual category. The same goes for any other meta-packages such as kde-meta-* or whatnot. [1] http://packages.gentoo.org/category/java-virtuals - -- Thanks, Zac - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiy81wACgkQ/ejvha5XGaNqfACg0jO+/Tk6s7+wVxHJoBtO+guU D3EAoKKs5LQbq+KDui8mJ/fVKyYf9N+v =8Aaf -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
On Mon, 25 Aug 2008 11:01:01 -0700 Zac Medico [EMAIL PROTECTED] wrote: Michal Kurgan wrote: On Sun, 24 Aug 2008 14:01:48 -0700 Zac Medico [EMAIL PROTECTED] wrote: Hi everyone, Since there were some questions about ambiguity in the meaning of the proposed PROPERTIES=virtual [1] value, we need to clarify it. [ ... ] Ebuilds that exhibit the virtual property commonly serve as a layer of indirection in dependencies. All of the ebuilds in the existing virtual category [4] should be eligible to define PROPERTIES=virtual. If the ebuilds in the virtual category were the only ones that exhibited this virtual property, then the information that PROPERTIES=virtual represents could simply be inferred from membership of that category. However, 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. Wouldn't it be more appropriate to just move the offending ebuilds to virtual category? e.g. virtual/qt, etc. A package move doesn't seem very practical given that the virtual property varies from one version to the next. I suppose it could be done as a split where older versions continue to exist as x11-libs/qt and newer versions exist as virtual/qt. Exactly. I think that this distinction is more clear, both for users and developers. You've got the idea about package just from its name, not internal structure such as PROPERTIES or DESCRIPTION variables. If we take that approach then you'll have to convince the java team to combine the whole java-virtuals category [1] into the virtual category. The same goes for any other meta-packages such as kde-meta-* or whatnot. [1] http://packages.gentoo.org/category/java-virtuals Hmm... looks like though work, but will try at least. Thanks for hint. If java hears that, what do you think about that? Are there any problems with doing such migration? - -- Thanks, Zac - -- Thanks, Zac -- Michal Kurgan http://dev.gentoo.org/~moloh
Re: [gentoo-dev] [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
On Sun, 24 Aug 2008 14:01:48 -0700 Zac Medico [EMAIL PROTECTED] wrote: Since there were some questions about ambiguity in the meaning of the proposed PROPERTIES=virtual [1] value, we need to clarify it. Just as the live property [2] is intended to have a pure and simple meaning, so is the virtual property. The virtual property will serve only as a hint, to indicate that dependency calculations should consider the package to have zero installation cost (see bug 141118 [3] for an example of why this knowledge is useful). The virtual property should not imply anything more than this, and therefore the package manager should assume that the package is to be treated exactly the same as other ebuilds in every other way. The package should be installed and uninstalled just like any other ebuild, including execution of all of the normal ebuild phase functions that would be executed for any other ebuild that does not exhibit the virtual property. So are all zero-install-cost metapackages virtuals now? What about, for instance, kde-base/kde? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: So are all zero-install-cost metapackages virtuals now? What about, for instance, kde-base/kde? Looking at the dependencies of kde-base/kde, it seems like it would be eligible to exhibit the virtual property. Perhaps it wouldn't be very useful in this particular case, but it doesn't seem like it would hurt anything either. So, I think it's probably fine to keep the definition as it is and allow things like kde-base/kde to exhibit the virtual property. - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkizArkACgkQ/ejvha5XGaNjmQCcC4EcX4jUOLBoombn6MuEu/Aa N7cAn1zymBJL/b8oZ/4bXWI4U/71uMRC =S7LN -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
On Mon, 25 Aug 2008 12:06:35 -0700 Zac Medico [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: So are all zero-install-cost metapackages virtuals now? What about, for instance, kde-base/kde? Looking at the dependencies of kde-base/kde, it seems like it would be eligible to exhibit the virtual property. Perhaps it wouldn't be very useful in this particular case, but it doesn't seem like it would hurt anything either. So, I think it's probably fine to keep the definition as it is and allow things like kde-base/kde to exhibit the virtual property. Then change the name. Call it zero-install-cost. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: On Mon, 25 Aug 2008 12:06:35 -0700 Zac Medico [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: So are all zero-install-cost metapackages virtuals now? What about, for instance, kde-base/kde? Looking at the dependencies of kde-base/kde, it seems like it would be eligible to exhibit the virtual property. Perhaps it wouldn't be very useful in this particular case, but it doesn't seem like it would hurt anything either. So, I think it's probably fine to keep the definition as it is and allow things like kde-base/kde to exhibit the virtual property. Then change the name. Call it zero-install-cost. 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. - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkizCcAACgkQ/ejvha5XGaO2WQCcCtL56YFoyBxNz5XUvPuJ/EMq GQsAoMLMDEk1Yd9N86SQUM1A92hntjFE =hwz3 -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
Zac Medico wrote: Then change the name. Call it zero-install-cost. 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. Zac, absolutely. ++ -Joe
Re: [gentoo-dev] [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
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.
[gentoo-dev] [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, Since there were some questions about ambiguity in the meaning of the proposed PROPERTIES=virtual [1] value, we need to clarify it. Just as the live property [2] is intended to have a pure and simple meaning, so is the virtual property. The virtual property will serve only as a hint, to indicate that dependency calculations should consider the package to have zero installation cost (see bug 141118 [3] for an example of why this knowledge is useful). The virtual property should not imply anything more than this, and therefore the package manager should assume that the package is to be treated exactly the same as other ebuilds in every other way. The package should be installed and uninstalled just like any other ebuild, including execution of all of the normal ebuild phase functions that would be executed for any other ebuild that does not exhibit the virtual property. Ebuilds that exhibit the virtual property commonly serve as a layer of indirection in dependencies. All of the ebuilds in the existing virtual category [4] should be eligible to define PROPERTIES=virtual. If the ebuilds in the virtual category were the only ones that exhibited this virtual property, then the information that PROPERTIES=virtual represents could simply be inferred from membership of that category. However, 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. Do the name and definition of this PROPERTIES=virtual value seem good? Would anybody like to discuss any changes to the name, definition, or both? [1] http://article.gmane.org/gmane.linux.gentoo.devel/57610 [2] http://archives.gentoo.org/gentoo-dev/msg_64b83155637bcad67478e2d2af276780.xml [3] http://bugs.gentoo.org/show_bug.cgi?id=141118 [4] http://packages.gentoo.org/category/virtual [5] http://packages.gentoo.org/category/java-virtuals [6] http://packages.gentoo.org/package/x11-libs/qt - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkixzDsACgkQ/ejvha5XGaMZngCeO6gYmAH1oKEaTNw3uu+K61HW gLcAn0KqYwUkmEdHI2W5v2x+qZBt1dYm =coqO -END PGP SIGNATURE-
