[gentoo-dev] RFC: splitting virtual/

[gentoo-dev] RFC: splitting virtual/

[Michał Górny]

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

Hello,

Now that we don't have any old-style virtuals in gx86 anymore,
I think the 'virtual' category is basically one another plain category
nowadays.

Considering the number of different virtuals in this category, maybe it
would be a good idea to split it a little? What I'm proposing is maybe
creating some kind of '*-virtual' categories.

For example, half of the current virtuals are prefixed with 'perl-'.
Maybe they could be transformed into 'perl-virtual/*'?

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] RFC: splitting virtual/

[Alec Warner]

On Mon, Aug 15, 2011 at 11:41 AM, Michał Górny <mgorny@gentoo.org> wrote:
> Hello,
>
> Now that we don't have any old-style virtuals in gx86 anymore,
> I think the 'virtual' category is basically one another plain category
> nowadays.
>
> Considering the number of different virtuals in this category, maybe it
> would be a good idea to split it a little? What I'm proposing is maybe
> creating some kind of '*-virtual' categories.
>
> For example, half of the current virtuals are prefixed with 'perl-'.
> Maybe they could be transformed into 'perl-virtual/*'?

why?

>
> --
> Best regards,
> Michał Górny
>

Re: [gentoo-dev] RFC: splitting virtual/

[Michał Górny]

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

On Mon, 15 Aug 2011 12:46:59 -0700
Alec Warner <antarus@gentoo.org> wrote:

> On Mon, Aug 15, 2011 at 11:41 AM, Michał Górny <mgorny@gentoo.org>
> wrote:
> > Hello,
> >
> > Now that we don't have any old-style virtuals in gx86 anymore,
> > I think the 'virtual' category is basically one another plain
> > category nowadays.
> >
> > Considering the number of different virtuals in this category,
> > maybe it would be a good idea to split it a little? What I'm
> > proposing is maybe creating some kind of '*-virtual' categories.
> >
> > For example, half of the current virtuals are prefixed with 'perl-'.
> > Maybe they could be transformed into 'perl-virtual/*'?
> 
> why?

Because I like categories much more than I do prefixes.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] RFC: splitting virtual/

[Patrick Lauer]

On 08/15/11 21:55, Michał Górny wrote:
> On Mon, 15 Aug 2011 12:46:59 -0700
> Alec Warner <antarus@gentoo.org> wrote:
> 
>> On Mon, Aug 15, 2011 at 11:41 AM, Michał Górny <mgorny@gentoo.org>
>> wrote:
>>> Hello,
>>>
>>> Now that we don't have any old-style virtuals in gx86 anymore,
>>> I think the 'virtual' category is basically one another plain
>>> category nowadays.
>>>
>>> Considering the number of different virtuals in this category,
>>> maybe it would be a good idea to split it a little? What I'm
>>> proposing is maybe creating some kind of '*-virtual' categories.
>>>
>>> For example, half of the current virtuals are prefixed with 'perl-'.
>>> Maybe they could be transformed into 'perl-virtual/*'?
>>
>> why?
> 
> Because I like categories much more than I do prefixes.
> 

But right now all virtuals are easily recognizable and nicely grouped
into one category. From my point of view that's the best categorization
we could ask for ... what would we gain from changing it?

Re: [gentoo-dev] RFC: splitting virtual/

[Philip Webb]

110815 Patrick Lauer wrote:
> On 08/15/11 21:55, Michał Górny wrote:
>> Considering the number of different virtuals in this category,
>> maybe it would be a good idea to split it a little?
>> -- maybe creating some kind of '*-virtual' categories.
>> For example, half of the current virtuals are prefixed with 'perl-'.
>> Maybe they could be transformed into 'perl-virtual/*'?
> right now all virtuals are easily recognizable
> and nicely grouped into one category.

If you're going to take that route, which mb a small improvement,
it sb 'virtual-perl', 'virtual-java' etc.
It would help users see more clearly what sundry virtuals are for:
the present size of the category is less important than clarity.

-- 
========================,,============================================
SUPPORT     ___________//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT    `-O----------O---'   purslowatchassdotutorontodotca

Re: [gentoo-dev] RFC: splitting virtual/

[Rafael Goncalves Martins]

On Mon, Aug 15, 2011 at 5:22 PM, Patrick Lauer <patrick@gentoo.org> wrote:
> On 08/15/11 21:55, Michał Górny wrote:
>> On Mon, 15 Aug 2011 12:46:59 -0700
>> Alec Warner <antarus@gentoo.org> wrote:
>>
>>> On Mon, Aug 15, 2011 at 11:41 AM, Michał Górny <mgorny@gentoo.org>
>>> wrote:
>>>> Hello,
>>>>
>>>> Now that we don't have any old-style virtuals in gx86 anymore,
>>>> I think the 'virtual' category is basically one another plain
>>>> category nowadays.
>>>>
>>>> Considering the number of different virtuals in this category,
>>>> maybe it would be a good idea to split it a little? What I'm
>>>> proposing is maybe creating some kind of '*-virtual' categories.
>>>>
>>>> For example, half of the current virtuals are prefixed with 'perl-'.
>>>> Maybe they could be transformed into 'perl-virtual/*'?
>>>
>>> why?
>>
>> Because I like categories much more than I do prefixes.
>>
>
> But right now all virtuals are easily recognizable and nicely grouped
> into one category. From my point of view that's the best categorization
> we could ask for ... what would we gain from changing it?
>

Nothing IMO.

+1 to keep virtuals as they are now.

Regards,

-- 
Rafael Goncalves Martins
Gentoo Linux developer
http://rafaelmartins.eng.br/

Re: [gentoo-dev] RFC: splitting virtual/

[Nirbheek Chauhan]

On Tue, Aug 16, 2011 at 12:11 AM, Michał Górny <mgorny@gentoo.org> wrote:
> Considering the number of different virtuals in this category, maybe it
> would be a good idea to split it a little? What I'm proposing is maybe
> creating some kind of '*-virtual' categories.
>
> For example, half of the current virtuals are prefixed with 'perl-'.
> Maybe they could be transformed into 'perl-virtual/*'?
>

 $ ls -1 /usr/portage/virtual/ | wc -l
155
 $ ls -1 /usr/portage/dev-libs/ | wc -l
370
 $ ls -1 /usr/portage/net-libs/ | wc -l
135
 $ ls -1 /usr/portage/dev-util/ | wc -l
278
 $ ls -1 /usr/portage/dev-perl/ | wc -l
1029

I don't see a pressing need to split virtual/ yet :)


-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Re: [gentoo-dev] RFC: splitting virtual/

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 125 bytes --]

On Monday, August 15, 2011 17:33:24 Nirbheek Chauhan wrote:
> I don't see a pressing need to split virtual/ yet :)

+1
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] RFC: splitting virtual/

[Zac Medico]

On 08/15/2011 11:41 AM, Michał Górny wrote:
> Hello,
> 
> Now that we don't have any old-style virtuals in gx86 anymore,
> I think the 'virtual' category is basically one another plain category
> nowadays.

In sys-apps/portage, the "virtual" category is used as a hint to the
dependency resolver it needs to look ahead in order to make the best
possible choices. For example, in order to solve bug #141118 [1], it
recursively expands virtual/jre and virtual/jdk in order to efficiently
satisfy a jre dependency with whatever jdk happens to be installed,
instead of pulling in a redundant jre.

> Considering the number of different virtuals in this category, maybe it
> would be a good idea to split it a little? What I'm proposing is maybe
> creating some kind of '*-virtual' categories.
> 
> For example, half of the current virtuals are prefixed with 'perl-'.
> Maybe they could be transformed into 'perl-virtual/*'?

If you're going to do that, then I'd suggest giving them some sort of
tag that the package manager can rely upon in order to identify them as
virtuals. For example, we could have the ebuilds set PROPERTIES=virtual
[2], or we could simply specify (in PMS) that any category whose name
matches the '*-virtual' pattern will contain virtuals.

[1] http://bugs.gentoo.org/show_bug.cgi?id=141118
[2]
http://archives.gentoo.org/gentoo-dev/msg_9d449a18a96a25a547fcfd40544085cf.xml
-- 
Thanks,
Zac

Re: [gentoo-dev] RFC: splitting virtual/

[Michał Górny]

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

On Mon, 15 Aug 2011 19:42:01 -0700
Zac Medico <zmedico@gentoo.org> wrote:

> On 08/15/2011 11:41 AM, Michał Górny wrote:
> > Hello,
> > 
> > Now that we don't have any old-style virtuals in gx86 anymore,
> > I think the 'virtual' category is basically one another plain
> > category nowadays.
> 
> In sys-apps/portage, the "virtual" category is used as a hint to the
> dependency resolver it needs to look ahead in order to make the best
> possible choices. For example, in order to solve bug #141118 [1], it
> recursively expands virtual/jre and virtual/jdk in order to
> efficiently satisfy a jre dependency with whatever jdk happens to be
> installed, instead of pulling in a redundant jre.

Isn't that another, ugly, non-PMS hack which makes people think they
are creating correct packages?

> > Considering the number of different virtuals in this category,
> > maybe it would be a good idea to split it a little? What I'm
> > proposing is maybe creating some kind of '*-virtual' categories.
> > 
> > For example, half of the current virtuals are prefixed with 'perl-'.
> > Maybe they could be transformed into 'perl-virtual/*'?
> 
> If you're going to do that, then I'd suggest giving them some sort of
> tag that the package manager can rely upon in order to identify them
> as virtuals. For example, we could have the ebuilds set
> PROPERTIES=virtual [2], or we could simply specify (in PMS) that any
> category whose name matches the '*-virtual' pattern will contain
> virtuals.

Doesn't DEFINED_PHASES==- serve that purpose nowadays?

> [1] http://bugs.gentoo.org/show_bug.cgi?id=141118
> [2]
> http://archives.gentoo.org/gentoo-dev/msg_9d449a18a96a25a547fcfd40544085cf.xml



-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] RFC: splitting virtual/

[Zac Medico]

On 08/16/2011 12:01 AM, Michał Górny wrote:
> On Mon, 15 Aug 2011 19:42:01 -0700
> Zac Medico <zmedico@gentoo.org> wrote:
> 
>> On 08/15/2011 11:41 AM, Michał Górny wrote:
>>> Hello,
>>>
>>> Now that we don't have any old-style virtuals in gx86 anymore,
>>> I think the 'virtual' category is basically one another plain
>>> category nowadays.
>>
>> In sys-apps/portage, the "virtual" category is used as a hint to the
>> dependency resolver it needs to look ahead in order to make the best
>> possible choices. For example, in order to solve bug #141118 [1], it
>> recursively expands virtual/jre and virtual/jdk in order to
>> efficiently satisfy a jre dependency with whatever jdk happens to be
>> installed, instead of pulling in a redundant jre.
> 
> Isn't that another, ugly, non-PMS hack which makes people think they
> are creating correct packages?

Are you saying that you'd prefer to have package managers pull in
redundant packages for not good reason?

Anyway, the thing that's really special about virtuals is that they can
be considered to contribute zero-cost when the package manager is trying
minimize the overall cost of satisfying a particular dependency. To
minimize cost means to eliminate redundant packages.

The relevance of virtuals in terms of cost calculations is why Ciaran
suggested to call it PROPERTIES="zero-install-cost" [1] instead of
"virtual".

>>> Considering the number of different virtuals in this category,
>>> maybe it would be a good idea to split it a little? What I'm
>>> proposing is maybe creating some kind of '*-virtual' categories.
>>>
>>> For example, half of the current virtuals are prefixed with 'perl-'.
>>> Maybe they could be transformed into 'perl-virtual/*'?
>>
>> If you're going to do that, then I'd suggest giving them some sort of
>> tag that the package manager can rely upon in order to identify them
>> as virtuals. For example, we could have the ebuilds set
>> PROPERTIES=virtual [2], or we could simply specify (in PMS) that any
>> category whose name matches the '*-virtual' pattern will contain
>> virtuals.
> 
> Doesn't DEFINED_PHASES==- serve that purpose nowadays?

That's an interesting idea. It seems like that should suffice for this
purpose.

[1]
http://archives.gentoo.org/gentoo-dev/msg_47dc8f61c43d835c3feee77244188b02.xml
-- 
Thanks,
Zac

Re: [gentoo-dev] RFC: splitting virtual/

[Ciaran McCreesh]

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

On Tue, 16 Aug 2011 00:19:38 -0700
Zac Medico <zmedico@gentoo.org> wrote:
> > Isn't that another, ugly, non-PMS hack which makes people think they
> > are creating correct packages?
> 
> Are you saying that you'd prefer to have package managers pull in
> redundant packages for not good reason?

No, package managers should get things right regardless of whether
something is in the 'virtual/' category or not. If they can't get
things right, then we need to supply them with more data.

And most importantly, you need to stop adding in short-sighted hacks to
'fix' one bug at the expense of consistency and quality.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RFC: splitting virtual/

[Zac Medico]

On 08/16/2011 02:32 AM, Ciaran McCreesh wrote:
> On Tue, 16 Aug 2011 00:19:38 -0700
> Zac Medico <zmedico@gentoo.org> wrote:
>>> Isn't that another, ugly, non-PMS hack which makes people think they
>>> are creating correct packages?
>>
>> Are you saying that you'd prefer to have package managers pull in
>> redundant packages for not good reason?
> 
> No, package managers should get things right regardless of whether
> something is in the 'virtual/' category or not. If they can't get
> things right, then we need to supply them with more data.

Consider the virtual/jre and virtual/jdk case. Suppose that virtual/jdk
isn't installed for some reason, but dev-java/sun-jdk which satisfies it
is already installed.  In this case, unless you know that virtual/jdk is
zero-cost, it's not clear that it costs less to install virtual/jdk than
to install dev-java/sun-jre-bin. There may be lots of cases like this
where zero-cost metadata would be useful.

> And most importantly, you need to stop adding in short-sighted hacks to
> 'fix' one bug at the expense of consistency and quality.

Call it what you want, but the behavior that I implemented for bug
141118 seems relatively optimal to me.
-- 
Thanks,
Zac

Re: [gentoo-dev] RFC: splitting virtual/

[Ciaran McCreesh]

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

On Tue, 16 Aug 2011 03:01:26 -0700
Zac Medico <zmedico@gentoo.org> wrote:
> On 08/16/2011 02:32 AM, Ciaran McCreesh wrote:
> > On Tue, 16 Aug 2011 00:19:38 -0700
> > Zac Medico <zmedico@gentoo.org> wrote:
> >>> Isn't that another, ugly, non-PMS hack which makes people think
> >>> they are creating correct packages?
> >>
> >> Are you saying that you'd prefer to have package managers pull in
> >> redundant packages for not good reason?
> > 
> > No, package managers should get things right regardless of whether
> > something is in the 'virtual/' category or not. If they can't get
> > things right, then we need to supply them with more data.
> 
> Consider the virtual/jre and virtual/jdk case. Suppose that
> virtual/jdk isn't installed for some reason, but dev-java/sun-jdk
> which satisfies it is already installed.  In this case, unless you
> know that virtual/jdk is zero-cost, it's not clear that it costs less
> to install virtual/jdk than to install dev-java/sun-jre-bin. There
> may be lots of cases like this where zero-cost metadata would be
> useful.

Uh huh, so rather than adding in a hack, we need a proper way of
identifying those cases.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RFC: splitting virtual/

[Michał Górny]

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

On Tue, 16 Aug 2011 03:01:26 -0700
Zac Medico <zmedico@gentoo.org> wrote:

> On 08/16/2011 02:32 AM, Ciaran McCreesh wrote:
> > On Tue, 16 Aug 2011 00:19:38 -0700
> > Zac Medico <zmedico@gentoo.org> wrote:
> >>> Isn't that another, ugly, non-PMS hack which makes people think
> >>> they are creating correct packages?
> >>
> >> Are you saying that you'd prefer to have package managers pull in
> >> redundant packages for not good reason?
> > 
> > No, package managers should get things right regardless of whether
> > something is in the 'virtual/' category or not. If they can't get
> > things right, then we need to supply them with more data.
> 
> Consider the virtual/jre and virtual/jdk case. Suppose that
> virtual/jdk isn't installed for some reason, but dev-java/sun-jdk
> which satisfies it is already installed.  In this case, unless you
> know that virtual/jdk is zero-cost, it's not clear that it costs less
> to install virtual/jdk than to install dev-java/sun-jre-bin. There
> may be lots of cases like this where zero-cost metadata would be
> useful.

Maybe virtual/jre & virtual/jdk should me merged into a single ebuild
with USE-switchable behavior? Something like:

RDEPEND="jdk? ( || ( a-jdk b-jdk ) )
	!jdk? ( || ( a-jre b-jre a-jdk b-jdk ) )"

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] RFC: splitting virtual/

[Zac Medico]

On 08/17/2011 12:20 AM, Michał Górny wrote:
> On Tue, 16 Aug 2011 03:01:26 -0700
> Zac Medico <zmedico@gentoo.org> wrote:
> 
>> On 08/16/2011 02:32 AM, Ciaran McCreesh wrote:
>>> On Tue, 16 Aug 2011 00:19:38 -0700
>>> Zac Medico <zmedico@gentoo.org> wrote:
>>>>> Isn't that another, ugly, non-PMS hack which makes people think
>>>>> they are creating correct packages?
>>>>
>>>> Are you saying that you'd prefer to have package managers pull in
>>>> redundant packages for not good reason?
>>>
>>> No, package managers should get things right regardless of whether
>>> something is in the 'virtual/' category or not. If they can't get
>>> things right, then we need to supply them with more data.
>>
>> Consider the virtual/jre and virtual/jdk case. Suppose that
>> virtual/jdk isn't installed for some reason, but dev-java/sun-jdk
>> which satisfies it is already installed.  In this case, unless you
>> know that virtual/jdk is zero-cost, it's not clear that it costs less
>> to install virtual/jdk than to install dev-java/sun-jre-bin. There
>> may be lots of cases like this where zero-cost metadata would be
>> useful.
> 
> Maybe virtual/jre & virtual/jdk should me merged into a single ebuild
> with USE-switchable behavior? Something like:
> 
> RDEPEND="jdk? ( || ( a-jdk b-jdk ) )
> 	!jdk? ( || ( a-jre b-jre a-jdk b-jdk ) )"

Here it seems like you're introducing a USE flag in order to overcome a
shortcoming of the dependency resolver.

Note that the jre and jdk relationship isn't necessarily the only
relationship with these properties. Wouldn't it be better to make the
dependency resolver a bit smarter (as implemented in portage for many
years), than to introduce a bunch of workarounds like the jdk USE flag
that you suggest?
-- 
Thanks,
Zac

Re: [gentoo-dev] RFC: splitting virtual/

[Ciaran McCreesh]

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

On Wed, 17 Aug 2011 06:27:36 -0700
Zac Medico <zmedico@gentoo.org> wrote:
> Note that the jre and jdk relationship isn't necessarily the only
> relationship with these properties. Wouldn't it be better to make the
> dependency resolver a bit smarter (as implemented in portage for many
> years), than to introduce a bunch of workarounds like the jdk USE flag
> that you suggest?

The dependency resolver can only be made smarter if it's given accurate
information about when it can be smart.

Random guesswork isn't accurate information.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RFC: splitting virtual/

[Zac Medico]

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

On 08/16/2011 12:01 AM, Micha? Górny wrote:
>>> Considering the number of different virtuals in this category, 
>>> maybe it would be a good idea to split it a little? What I'm 
>>> proposing is maybe creating some kind of '*-virtual' categories.
>>> 
>>> For example, half of the current virtuals are prefixed with
>>> 'perl-'. Maybe they could be transformed into 'perl-virtual/*'?
>> 
>> If you're going to do that, then I'd suggest giving them some sort
>> of tag that the package manager can rely upon in order to identify
>> them as virtuals. For example, we could have the ebuilds set 
>> PROPERTIES=virtual [2], or we could simply specify (in PMS) that
>> any category whose name matches the '*-virtual' pattern will
>> contain virtuals.
> 
> Doesn't DEFINED_PHASES==- serve that purpose nowadays?

Actually, since EAPI 4 we have default src_install, so it's possible to
have ebuilds that have no defined phases but still install stuff.
- -- 
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk5KG7EACgkQ/ejvha5XGaOIeACfSLRu2svBgk3zYi+bBD7HI6hP
cjcAoJ2vqzeyXza8+p4FTlvK/Wjt6HXv
=KlFM
-----END PGP SIGNATURE-----

Re: [gentoo-dev] RFC: splitting virtual/

[Michał Górny]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Tue, 16 Aug 2011 00:26:41 -0700
Zac Medico <zmedico@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 08/16/2011 12:01 AM, Micha? Górny wrote:
> >>> Considering the number of different virtuals in this category, 
> >>> maybe it would be a good idea to split it a little? What I'm 
> >>> proposing is maybe creating some kind of '*-virtual' categories.
> >>> 
> >>> For example, half of the current virtuals are prefixed with
> >>> 'perl-'. Maybe they could be transformed into 'perl-virtual/*'?
> >> 
> >> If you're going to do that, then I'd suggest giving them some sort
> >> of tag that the package manager can rely upon in order to identify
> >> them as virtuals. For example, we could have the ebuilds set 
> >> PROPERTIES=virtual [2], or we could simply specify (in PMS) that
> >> any category whose name matches the '*-virtual' pattern will
> >> contain virtuals.
> > 
> > Doesn't DEFINED_PHASES==- serve that purpose nowadays?
> 
> Actually, since EAPI 4 we have default src_install, so it's possible
> to have ebuilds that have no defined phases but still install stuff.

+ empty SRC_URI? I guess something like the workdir fallback conditions
in PMS.

- -- 
Best regards,
Michał Górny
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iJwEAQEIAAYFAk5KHv8ACgkQfXuS5UK5QB0PbgP9GupYR9x+mTGrLfGeGeNH5qE9
RfkK1N4lLyU+yaekwEVpAWlQlRfm7Fi/p7kjsDF9sOCQ3QHJhtLv2kCdDrwmucAr
lnNKgz48bHn9CDc+zdBHlTox8ll93vwVEIxL5+gEgZK67RD6Z6Of+yVSrGJPVgQi
UqSEvRk8HbyLD3Tdg8g=
=jaP+
-----END PGP SIGNATURE-----

Re: [gentoo-dev] RFC: splitting virtual/

[Zac Medico]

On 08/16/2011 12:40 AM, Michał Górny wrote:
> On Tue, 16 Aug 2011 00:26:41 -0700
> Zac Medico <zmedico@gentoo.org> wrote:
>> On 08/16/2011 12:01 AM, Micha? Górny wrote:
>>>>> Considering the number of different virtuals in this category, 
>>>>> maybe it would be a good idea to split it a little? What I'm 
>>>>> proposing is maybe creating some kind of '*-virtual' categories.
>>>>>
>>>>> For example, half of the current virtuals are prefixed with
>>>>> 'perl-'. Maybe they could be transformed into 'perl-virtual/*'?
>>>>
>>>> If you're going to do that, then I'd suggest giving them some sort
>>>> of tag that the package manager can rely upon in order to identify
>>>> them as virtuals. For example, we could have the ebuilds set 
>>>> PROPERTIES=virtual [2], or we could simply specify (in PMS) that
>>>> any category whose name matches the '*-virtual' pattern will
>>>> contain virtuals.
>>>
>>> Doesn't DEFINED_PHASES==- serve that purpose nowadays?
> 
>> Actually, since EAPI 4 we have default src_install, so it's possible
>> to have ebuilds that have no defined phases but still install stuff.
> 
> + empty SRC_URI? I guess something like the workdir fallback conditions
> in PMS.

When you consider that "live" ebuilds can have empty SRC_URI and
download things during src_unpack, it seems more sensible and simple to
introduce PROPERTIES="live" or something like it. That way, we'll have a
simple boolean flag and won't have to make any fragile assumptions.
-- 
Thanks,
Zac

Re: [gentoo-dev] RFC: splitting virtual/

[Michał Górny]

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

On Tue, 16 Aug 2011 01:10:48 -0700
Zac Medico <zmedico@gentoo.org> wrote:

> On 08/16/2011 12:40 AM, Michał Górny wrote:
> > On Tue, 16 Aug 2011 00:26:41 -0700
> > Zac Medico <zmedico@gentoo.org> wrote:
> >> On 08/16/2011 12:01 AM, Micha? Górny wrote:
> >>>>> Considering the number of different virtuals in this category, 
> >>>>> maybe it would be a good idea to split it a little? What I'm 
> >>>>> proposing is maybe creating some kind of '*-virtual' categories.
> >>>>>
> >>>>> For example, half of the current virtuals are prefixed with
> >>>>> 'perl-'. Maybe they could be transformed into 'perl-virtual/*'?
> >>>>
> >>>> If you're going to do that, then I'd suggest giving them some
> >>>> sort of tag that the package manager can rely upon in order to
> >>>> identify them as virtuals. For example, we could have the
> >>>> ebuilds set PROPERTIES=virtual [2], or we could simply specify
> >>>> (in PMS) that any category whose name matches the '*-virtual'
> >>>> pattern will contain virtuals.
> >>>
> >>> Doesn't DEFINED_PHASES==- serve that purpose nowadays?
> > 
> >> Actually, since EAPI 4 we have default src_install, so it's
> >> possible to have ebuilds that have no defined phases but still
> >> install stuff.
> > 
> > + empty SRC_URI? I guess something like the workdir fallback
> > conditions in PMS.
> 
> When you consider that "live" ebuilds can have empty SRC_URI and
> download things during src_unpack, it seems more sensible and simple
> to introduce PROPERTIES="live" or something like it. That way, we'll
> have a simple boolean flag and won't have to make any fragile
> assumptions.

Live ebuild have to redefine src_unpack() which makes DEFINED_PHASES!=-.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] RFC: splitting virtual/

[Zac Medico]

On 08/16/2011 01:29 AM, Michał Górny wrote:
> On Tue, 16 Aug 2011 01:10:48 -0700
> Zac Medico <zmedico@gentoo.org> wrote:
> 
>> On 08/16/2011 12:40 AM, Michał Górny wrote:
>>> On Tue, 16 Aug 2011 00:26:41 -0700
>>> Zac Medico <zmedico@gentoo.org> wrote:
>>>> On 08/16/2011 12:01 AM, Micha? Górny wrote:
>>>>>>> Considering the number of different virtuals in this category, 
>>>>>>> maybe it would be a good idea to split it a little? What I'm 
>>>>>>> proposing is maybe creating some kind of '*-virtual' categories.
>>>>>>>
>>>>>>> For example, half of the current virtuals are prefixed with
>>>>>>> 'perl-'. Maybe they could be transformed into 'perl-virtual/*'?
>>>>>>
>>>>>> If you're going to do that, then I'd suggest giving them some
>>>>>> sort of tag that the package manager can rely upon in order to
>>>>>> identify them as virtuals. For example, we could have the
>>>>>> ebuilds set PROPERTIES=virtual [2], or we could simply specify
>>>>>> (in PMS) that any category whose name matches the '*-virtual'
>>>>>> pattern will contain virtuals.
>>>>>
>>>>> Doesn't DEFINED_PHASES==- serve that purpose nowadays?
>>>
>>>> Actually, since EAPI 4 we have default src_install, so it's
>>>> possible to have ebuilds that have no defined phases but still
>>>> install stuff.
>>>
>>> + empty SRC_URI? I guess something like the workdir fallback
>>> conditions in PMS.
>>
>> When you consider that "live" ebuilds can have empty SRC_URI and
>> download things during src_unpack, it seems more sensible and simple
>> to introduce PROPERTIES="live" or something like it. That way, we'll
>> have a simple boolean flag and won't have to make any fragile
>> assumptions.
> 
> Live ebuild have to redefine src_unpack() which makes DEFINED_PHASES!=-.

Sure, but the fact that you have to check two variables like that and
make these fragile assumptions makes it seem like we're building a
fragile kludge rather than something that's really practical.
-- 
Thanks,
Zac

Re: [gentoo-dev] RFC: splitting virtual/

[Michał Górny]

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

On Tue, 16 Aug 2011 01:51:27 -0700
Zac Medico <zmedico@gentoo.org> wrote:

> On 08/16/2011 01:29 AM, Michał Górny wrote:
> > On Tue, 16 Aug 2011 01:10:48 -0700
> > Zac Medico <zmedico@gentoo.org> wrote:
> > 
> >> On 08/16/2011 12:40 AM, Michał Górny wrote:
> >>> On Tue, 16 Aug 2011 00:26:41 -0700
> >>> Zac Medico <zmedico@gentoo.org> wrote:
> >>>> On 08/16/2011 12:01 AM, Micha? Górny wrote:
> >>>>>>> Considering the number of different virtuals in this
> >>>>>>> category, maybe it would be a good idea to split it a little?
> >>>>>>> What I'm proposing is maybe creating some kind of '*-virtual'
> >>>>>>> categories.
> >>>>>>>
> >>>>>>> For example, half of the current virtuals are prefixed with
> >>>>>>> 'perl-'. Maybe they could be transformed into
> >>>>>>> 'perl-virtual/*'?
> >>>>>>
> >>>>>> If you're going to do that, then I'd suggest giving them some
> >>>>>> sort of tag that the package manager can rely upon in order to
> >>>>>> identify them as virtuals. For example, we could have the
> >>>>>> ebuilds set PROPERTIES=virtual [2], or we could simply specify
> >>>>>> (in PMS) that any category whose name matches the '*-virtual'
> >>>>>> pattern will contain virtuals.
> >>>>>
> >>>>> Doesn't DEFINED_PHASES==- serve that purpose nowadays?
> >>>
> >>>> Actually, since EAPI 4 we have default src_install, so it's
> >>>> possible to have ebuilds that have no defined phases but still
> >>>> install stuff.
> >>>
> >>> + empty SRC_URI? I guess something like the workdir fallback
> >>> conditions in PMS.
> >>
> >> When you consider that "live" ebuilds can have empty SRC_URI and
> >> download things during src_unpack, it seems more sensible and
> >> simple to introduce PROPERTIES="live" or something like it. That
> >> way, we'll have a simple boolean flag and won't have to make any
> >> fragile assumptions.
> > 
> > Live ebuild have to redefine src_unpack() which makes
> > DEFINED_PHASES!=-.
> 
> Sure, but the fact that you have to check two variables like that and
> make these fragile assumptions makes it seem like we're building a
> fragile kludge rather than something that's really practical.

And isn't a random PROPERTIES value more fragile? If someone uses it
incorrectly, the results are undefined. With older PMs, results are
undefined.

While having empty SRC_URI and no DEFINED_PHASES guarantees that
the ebuild won't install a file. That's just per-def, nothing can
happen.

And still I think implementing stuff like that is just an ugly hack
instead of fixing the real issue.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] RFC: splitting virtual/

[Ulrich Mueller]

>>>>> On Wed, 17 Aug 2011, Michał Górny wrote:

> And isn't a random PROPERTIES value more fragile? If someone uses it
> incorrectly, the results are undefined. With older PMs, results are
> undefined.

> While having empty SRC_URI and no DEFINED_PHASES guarantees that
> the ebuild won't install a file. That's just per-def, nothing can
> happen.

Unfortunately, the inverse is not true. There are virtuals that
define phase functions, see virtual/ruby-* for example.

Ulrich

Re: [gentoo-dev] RFC: splitting virtual/

[Michał Górny]

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

On Wed, 17 Aug 2011 10:19:06 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:

> >>>>> On Wed, 17 Aug 2011, Michał Górny wrote:
> 
> > And isn't a random PROPERTIES value more fragile? If someone uses it
> > incorrectly, the results are undefined. With older PMs, results are
> > undefined.
> 
> > While having empty SRC_URI and no DEFINED_PHASES guarantees that
> > the ebuild won't install a file. That's just per-def, nothing can
> > happen.
> 
> Unfortunately, the inverse is not true. There are virtuals that
> define phase functions, see virtual/ruby-* for example.

And that's another issue in the ebuild. It should be fixed so that
phase functions won't be exported in the first place rather than
redefining them. This way, PM could assume it doesn't need to execute
those at all rather than running dummy code.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] RFC: splitting virtual/

[Zac Medico]

On 08/17/2011 10:03 AM, Michał Górny wrote:
> On Wed, 17 Aug 2011 10:19:06 +0200
> Ulrich Mueller <ulm@gentoo.org> wrote:
> 
>>>>>>> On Wed, 17 Aug 2011, Michał Górny wrote:
>>
>>> And isn't a random PROPERTIES value more fragile? If someone uses it
>>> incorrectly, the results are undefined. With older PMs, results are
>>> undefined.
>>
>>> While having empty SRC_URI and no DEFINED_PHASES guarantees that
>>> the ebuild won't install a file. That's just per-def, nothing can
>>> happen.
>>
>> Unfortunately, the inverse is not true. There are virtuals that
>> define phase functions, see virtual/ruby-* for example.
> 
> And that's another issue in the ebuild. It should be fixed so that
> phase functions won't be exported in the first place rather than
> redefining them. This way, PM could assume it doesn't need to execute
> those at all rather than running dummy code.

You can insist on this SRC_URI + DEFINED_PHASES approach, but I doubt
that package manager developers will want to rely on these kinds of
fragile assumptions. You thought that relying on the "virtual" category
name was ridiculous, but this SRC_URI + DEFINED_PHASES approach seems
must less practical to me.
-- 
Thanks,
Zac

Re: [gentoo-dev] RFC: splitting virtual/

[Ciaran McCreesh]

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

On Wed, 17 Aug 2011 10:58:32 -0700
Zac Medico <zmedico@gentoo.org> wrote:
> You can insist on this SRC_URI + DEFINED_PHASES approach, but I doubt
> that package manager developers will want to rely on these kinds of
> fragile assumptions. You thought that relying on the "virtual"
> category name was ridiculous, but this SRC_URI + DEFINED_PHASES
> approach seems must less practical to me.

The difference is, SRC_URI + DEFINED_PHASES is guaranteed to work.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RFC: splitting virtual/

[Ulrich Mueller]

>>>>> On Wed, 17 Aug 2011, Ciaran McCreesh wrote:

> On Wed, 17 Aug 2011 10:58:32 -0700
> Zac Medico <zmedico@gentoo.org> wrote:
>> You can insist on this SRC_URI + DEFINED_PHASES approach, but I
>> doubt that package manager developers will want to rely on these
>> kinds of fragile assumptions. You thought that relying on the
>> "virtual" category name was ridiculous, but this SRC_URI +
>> DEFINED_PHASES approach seems must less practical to me.

> The difference is, SRC_URI + DEFINED_PHASES is guaranteed to work.

Adding explicit information to PROPERTIES still looks much cleaner
to me.

And as previously noted, not every virtual (or meta package) has empty
DEFINED_PHASES.

Ulrich

Re: [gentoo-dev] RFC: splitting virtual/

[Zac Medico]

On 08/17/2011 12:16 AM, Michał Górny wrote:
> On Tue, 16 Aug 2011 01:51:27 -0700
> Zac Medico <zmedico@gentoo.org> wrote:
> 
>> On 08/16/2011 01:29 AM, Michał Górny wrote:
>>> On Tue, 16 Aug 2011 01:10:48 -0700
>>> Zac Medico <zmedico@gentoo.org> wrote:
>>>
>>>> On 08/16/2011 12:40 AM, Michał Górny wrote:
>>>>> On Tue, 16 Aug 2011 00:26:41 -0700
>>>>> Zac Medico <zmedico@gentoo.org> wrote:
>>>>>> On 08/16/2011 12:01 AM, Micha? Górny wrote:
>>>>>>>>> Considering the number of different virtuals in this
>>>>>>>>> category, maybe it would be a good idea to split it a little?
>>>>>>>>> What I'm proposing is maybe creating some kind of '*-virtual'
>>>>>>>>> categories.
>>>>>>>>>
>>>>>>>>> For example, half of the current virtuals are prefixed with
>>>>>>>>> 'perl-'. Maybe they could be transformed into
>>>>>>>>> 'perl-virtual/*'?
>>>>>>>>
>>>>>>>> If you're going to do that, then I'd suggest giving them some
>>>>>>>> sort of tag that the package manager can rely upon in order to
>>>>>>>> identify them as virtuals. For example, we could have the
>>>>>>>> ebuilds set PROPERTIES=virtual [2], or we could simply specify
>>>>>>>> (in PMS) that any category whose name matches the '*-virtual'
>>>>>>>> pattern will contain virtuals.
>>>>>>>
>>>>>>> Doesn't DEFINED_PHASES==- serve that purpose nowadays?
>>>>>
>>>>>> Actually, since EAPI 4 we have default src_install, so it's
>>>>>> possible to have ebuilds that have no defined phases but still
>>>>>> install stuff.
>>>>>
>>>>> + empty SRC_URI? I guess something like the workdir fallback
>>>>> conditions in PMS.
>>>>
>>>> When you consider that "live" ebuilds can have empty SRC_URI and
>>>> download things during src_unpack, it seems more sensible and
>>>> simple to introduce PROPERTIES="live" or something like it. That
>>>> way, we'll have a simple boolean flag and won't have to make any
>>>> fragile assumptions.
>>>
>>> Live ebuild have to redefine src_unpack() which makes
>>> DEFINED_PHASES!=-.
>>
>> Sure, but the fact that you have to check two variables like that and
>> make these fragile assumptions makes it seem like we're building a
>> fragile kludge rather than something that's really practical.
> 
> And isn't a random PROPERTIES value more fragile?

Well, if we could have simply relied upon a single variable like
DEFINED_PHASES, then that approach would have been preferable. But since
it would require making fragile assumptions about DEFINED_PHASES and
SRC_URI variables, I think PROPERTIES would be a much more practical
approach.

> If someone uses it
> incorrectly, the results are undefined.

I don't think it's a difficult concept to grasp, so I think it's
unlikely to be used incorrectly. Even if it is used incorrectly, I don't
see it causing major problems.

> With older PMs, results are
> undefined.

The worst case is that some redundant packages are pulled into the
dependency graph, which is the legacy behavior anyway, so there's no net
loss.

> While having empty SRC_URI and no DEFINED_PHASES guarantees that
> the ebuild won't install a file. That's just per-def, nothing can
> happen.

As Ulrich has already mentioned, virtual/ruby-* define phases, so your
fragile assumptions are falling apart again.

> And still I think implementing stuff like that is just an ugly hack
> instead of fixing the real issue.

Is the real issue that ebuild developers aren't using workarounds in
order to overcome the shortcomings of some dependency resolvers? Really?
-- 
Thanks,
Zac

Re: [gentoo-dev] RFC: splitting virtual/

[Ciaran McCreesh]

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

On Wed, 17 Aug 2011 06:40:45 -0700
Zac Medico <zmedico@gentoo.org> wrote:
> Is the real issue that ebuild developers aren't using workarounds in
> order to overcome the shortcomings of some dependency resolvers?
> Really?

The real issue is that Portage has nearly as much unspecified voodoo
in its behaviour as a web browser.

If you think there are particular cases where resolution should be
smarter then the way to proceed is to introduce well-specified
metadata to handle it -- and, importantly, you should *not* implement
a dodgy workaround in the mean time. There shouldn't be any weird
magical difference in behaviour based upon package name, and if
something isn't done properly then it shouldn't be there at all.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RFC: splitting virtual/

[Zac Medico]

On 08/17/2011 07:24 AM, Ciaran McCreesh wrote:
> On Wed, 17 Aug 2011 06:40:45 -0700
> Zac Medico <zmedico@gentoo.org> wrote:
>> Is the real issue that ebuild developers aren't using workarounds in
>> order to overcome the shortcomings of some dependency resolvers?
>> Really?
> 
> The real issue is that Portage has nearly as much unspecified voodoo
> in its behaviour as a web browser.
> 
> If you think there are particular cases where resolution should be
> smarter then the way to proceed is to introduce well-specified
> metadata to handle it

Agreed. Obviously, I'm in favor of introducing this metadata that you
speak of.

> -- and, importantly, you should *not* implement
> a dodgy workaround in the mean time. There shouldn't be any weird
> magical difference in behaviour based upon package name, and if
> something isn't done properly then it shouldn't be there at all.

That's in the past now. Let's move forward with the introduction of the
new metadata!
-- 
Thanks,
Zac