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

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

[Zac Medico]

-----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-----

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

[Michal Kurgan]

On Sun, 24 Aug 2008 14:01:48 -0700
Zac Medico <zmedico@gentoo.org> 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)

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michal Kurgan wrote:
> On Sun, 24 Aug 2008 14:01:48 -0700
> Zac Medico <zmedico@gentoo.org> 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)

[Michal Kurgan]

On Mon, 25 Aug 2008 11:01:01 -0700
Zac Medico <zmedico@gentoo.org> wrote:

> Michal Kurgan wrote:
> > On Sun, 24 Aug 2008 14:01:48 -0700
> > Zac Medico <zmedico@gentoo.org> 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)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1133 bytes --]

On Sun, 24 Aug 2008 14:01:48 -0700
Zac Medico <zmedico@gentoo.org> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Zac Medico]

-----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)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 672 bytes --]

On Mon, 25 Aug 2008 12:06:35 -0700
Zac Medico <zmedico@gentoo.org> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ciaran McCreesh wrote:
> On Mon, 25 Aug 2008 12:06:35 -0700
> Zac Medico <zmedico@gentoo.org> 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)

[Joe Peterson]

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)

[David Leverton]

On Monday 25 August 2008 20:36:34 Zac Medico wrote:
> > Zac Medico <zmedico@gentoo.org> 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] Re: [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)

[Duncan]

David Leverton <levertond@googlemail.com> posted
200808252103.27006.levertond@googlemail.com, excerpted below, on  Mon, 25
Aug 2008 21:03:26 +0100:

> On Monday 25 August 2008 20:36:34 Zac Medico wrote:
>> > Zac Medico <zmedico@gentoo.org> 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

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 796 bytes --]

On Tue, 26 Aug 2008 06:39:38 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Duncan]

Ciaran McCreesh <ciaran.mccreesh@googlemail.com> posted
20080826142044.28367055@googlemail.com, excerpted below, on  Tue, 26 Aug
2008 14:20:44 +0100:

> On Tue, 26 Aug 2008 06:39:38 +0000 (UTC) Duncan <1i5t5.duncan@cox.net>
> 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:

        <jargon, architecture> (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)

[Zac Medico]

-----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)

[Duncan]

Zac Medico <zmedico@gentoo.org> posted 48B440F6.7020705@gentoo.org,
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)

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Duncan wrote:
> Zac Medico <zmedico@gentoo.org> posted 48B440F6.7020705@gentoo.org,
> 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-----

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

[Michal Kurgan]

On Tue, 26 Aug 2008 18:49:12 -0700
Zac Medico <zmedico@gentoo.org> 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)

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michal Kurgan wrote:
> On Tue, 26 Aug 2008 18:49:12 -0700
> Zac Medico <zmedico@gentoo.org> 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)

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Zac Medico wrote:
> Michal Kurgan wrote:
>> On Tue, 26 Aug 2008 18:49:12 -0700
>> Zac Medico <zmedico@gentoo.org> 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)

[Jorge Manuel B. S. Vicetto]

-----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-----

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

[Steve Long]

Duncan wrote:

> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> posted
> 20080826142044.28367055@googlemail.com, excerpted below, on  Tue, 26 Aug
> 2008 14:20:44 +0100:
> 
>> On Tue, 26 Aug 2008 06:39:38 +0000 (UTC) Duncan <1i5t5.duncan@cox.net>
>> 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)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1056 bytes --]

On Sat, 30 Aug 2008 10:59:41 +0100
Steve Long <slong@rathaus.eclipse.co.uk> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Steve Long]

Ciaran McCreesh wrote:

> On Sat, 30 Aug 2008 10:59:41 +0100
> Steve Long <slong@rathaus.eclipse.co.uk> 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.)

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1533 bytes --]

On Sun, 31 Aug 2008 03:29:16 +0100
Steve Long <slong@rathaus.eclipse.co.uk> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Joe Peterson]

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

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

[Duncan]

Joe Peterson <lavajoe@gentoo.org> posted 48BAECC2.80403@gentoo.org,
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)

[Marius Mauch]

On Tue, 26 Aug 2008 14:20:07 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> 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

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

[Marius Mauch]

On Sun, 24 Aug 2008 14:01:48 -0700
Zac Medico <zmedico@gentoo.org> 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)

[Joe Peterson]

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)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1118 bytes --]

On Fri, 05 Sep 2008 09:38:32 -0600
Joe Peterson <lavajoe@gentoo.org> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Joe Peterson]

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

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

[Steve Long]

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)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1391 bytes --]

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.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Steve Long]

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.