[gentoo-dev] Virtuals revisited (Round 3)

[gentoo-dev] Virtuals revisited (Round 3)

[Jason Stubbs]

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

Hi all,

Back in my quest to rid the tree of the evil virtuals and their plot to 
destroy my mind. I think I've covered all bases with this one - perhaps even 
enough to satisfy TGL. Take your best shot!

Regards,
Jason Stubbs

[-- Attachment #2: virtuals-glep.txt --]
[-- Type: text/plain, Size: 6738 bytes --]

GLEP: XXX
Title: Virtuals Deprecation
Version: $Revision: 1.4 $
Last-Modified: $Date: 2003/07/19 12:09:20 $
Author:	Jason Stubbs <jstubbs@gentoo.org>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 06-May-2005
Post-History: 07-May-2005


Credits
=======

Most ideas in this GLEP came out of discussion with Thomas de Grenier de
Latour.  Ciaran McCreesh, Brian Harring and Stephen Bennett have also provided
help in fleshing out the idea.


Abstract
========

This GLEP covers the pitfalls of the current virtuals system, the benefits of
using regular ebuilds to serve the purpose of virtuals and what needs to be
supported to make it viable.


Motivation
==========

The current virtuals system is decentralized; that is there is no way to find
information about a specific virtual other than to scan all packages for what
they provide.  There is also no way to tell whether an atom is a virtual or
not - yes, the "virtual/" prefix could have been used but it isn't which has
led to its abuse.

What this means is that portage must scan all installed packages for the
virtuals they provide, that profiles must provide a default for every single
virtual that portage might encounter and that every single atom that portage
processes must be checked against the list of virtuals.  Needless to say that
this causes quite a performance decrease.

The current virtuals system also has some other major shortcomings.  The most
well known case is virtual/jdk and kaffe.  Kaffe-1.1.4 implements the Java 1.4
API but can not satisfy a package that requires >=virtual/jdk-1.4 because
kaffe's versioning scheme differs.  (ED: Need to add some more here. ;)


Specification
=============

This GLEP recommends that virtuals become no different to regular packages.
Specifically, the standard virtual would include the DESCRIPTION, KEYWORDS,
IUSE, DEPEND and RDEPEND metadata.  However, there are some issues that have
been brought up with doing this.


Consistency
-----------

Presently, it is very easy to remove packages even if others are dependent
on them, which can lead to broken emerges when packages rely on indirect
dependencies.  For example, if kdelibs is merged bringing in qt and then
qt is unmerged, attempting to merge kdebase will likely fail.  This becomes
a much bigger problem with virtuals as packages because the dependencies
are always indirect.

The resolution for this issue will be to add full dependency tracking and
verification to portage.  The details of how it will be done are outside the
scope of this GLEP, but essentially this means that portage will need to be
forced to unmerge a package that is depended on by another and will also be
able to scan and fix any broken dependencies.


Overrides
---------

Profiles currently specify the default provider of each virtual and users are
able to override these defaults using /etc/portage/profile/virtuals.  If
virtuals are replaced by regular packages and thus able to have arbitrarily
complex DEPENDs, the current method of overriding default virtuals can not
be extended to support this.

Before looking at a solution, lets look at how the current system works.  When
portage initializes, it searches installed packages for available virtuals.
It then searches profiles and user overrides and adds them to the available
providers list and/or changes the order of the providers so that overrides are
listed earlier.  Portage then expands any virtual atom it finds into an OR
list using the order decided upon at initialization.

To keep this behaviour available, this GLEP proposes a new file named
package.prefer.  In its basic form, this is just a list of package names
ordered by preference.  Portage would use it by reordering the atoms of any
OR list it processes to fit the order given by package.prefer.  For example,
if package.prefer contained "dev-java/kaffe" then:

::
	
	|| (
	    dev-java/blackdown-jdk
	    dev-java/sun-jdk
	    dev-java/kaffe
	   )

would be processed as:

::
	
	|| (
	    dev-java/kaffe
	    dev-java/blackdown-jdk
	    dev-java/sun-jdk
	   )

In its basic form, package.prefer already covers profile and user overrides.
However, this GLEP proposes that any type of atom be usable.  This will be
accomplished by checking for intersections of the atoms in the OR list and
atoms in the preferred list.  When an intersection is found, both atoms
would be specified in a sublist, which would then be treated as a ranged dep.
For example, if package.prefer contained "<=dev-java/sun-jdk-1.4" then:

::
	
	|| (
	    >=dev-java/blackdown-jdk-1.3
	    >=dev-java/sun-jdk-1.3
	   )

would be processed as:

::
	
	|| (
	    (
	      <=dev-java/sun-jdk-1.4
	      >=dev-java/sun-jdk-1.3
	    )
	    >=dev-java/blackdown-jdk-1.3
	    >=dev-java/sun-jdk-1.3
	   )

Ranged deps are outside of the scope of this GLEP.


Rationale
=========

The number one advantage is that it offers more power to both the user and
the developer.  Flexibility of virtuals is far greater in this scheme and
fulfills requirements that exist already.  It also means that the maintainers
of profiles will not need to list a default for every virtual.  The user
benefits by being able to easily gather a list of providers of a virtual as
well as their control being extended to allow selection where there is a
choice within any package.

Portage code also benefits from this scheme as virtuals will no longer
require special handling or dual implementations of essentially the same
feature, for example USE-based PROVIDEs.  This scheme is also much easier to
optimize which will benefit the processing of all packages.  It also means
that any additions to the DEPEND vocabulary become available for use in the
definitions of virtuals.


Backwards Compatibility
=======================

As the virtuals would just become like any other package, existing portages
will be able to handle them already.  When the tree is stripped of PROVIDEs
and "virtuals" override files, the only virtuals that existing portages will
use are those that the user has specified and those gleaned from installed
packages.  Any unknown virtual will be treated like a regular package and
looked for in the tree.

The only "issue" is that consistency checking and support for overrides are
not available in current versions of portage.  However, before releasing a
version of portage that no longer supports virtuals, it is planned to release
a version that has support for consistency checking.

When the time comes to migrate, scripts can be easily be written to create
packages from the existing virtuals system as well as to create appropriate
package.prefer overrides within the profiles.


Copyright
=========

This document has been placed in the public domain.

Re: [gentoo-dev] Virtuals revisited (Round 3)

[Ciaran McCreesh]

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

On Thu, 7 Apr 2005 22:20:43 +0900 Jason Stubbs <jstubbs@gentoo.org>
wrote:
| Back in my quest to rid the tree of the evil virtuals and their plot
| to  destroy my mind. I think I've covered all bases with this one -
| perhaps even  enough to satisfy TGL. Take your best shot!

1) You need an explicit example of what virtual/jdk/jdk-1.4.ebuild looks
like.

2) For the consistency section, I'm not sure how you're going to
implement this. The example I tend to use is this (versions simplified
slightly for clarity):

* User emerges vim-6.3, gvim-6.3. ~vim-core-6.3 is in as an RDEPEND.
* User upgrades to vim-7.0. ~vim-7.0 is in as an RDEPEND.
* User still has gvim-6.3 installed. gvim-6.3 has an RDEPEND upon
~vim-6.3, which is no longer installed. gvim is now broken.

An example of exactly how portage would 'solve' this would be
helpful. Would it ask for an unmerge of gvim-6.3 or would it include an
upgrade of gvim-6.3 as part of the "emerge ~vim-7"?

3) We don't specify every virtual in every profile thanks to cascades.

4) Backwards compatibility -- all virtuals ebuilds should include
DEPEND=">=portage-2.whatever" as well as the "|| ( foo bar )" stuff.

5) Someone tie up TGL and don't let him escape until he agrees to be a
dev this time.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Fluxbox, shell tools)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Virtuals revisited (Round 3)

[Jason Stubbs]

On Thursday 07 April 2005 23:26, Ciaran McCreesh wrote:
> On Thu, 7 Apr 2005 22:20:43 +0900 Jason Stubbs <jstubbs@gentoo.org>
> wrote:
> | Back in my quest to rid the tree of the evil virtuals and their plot
> | to  destroy my mind. I think I've covered all bases with this one -
> | perhaps even  enough to satisfy TGL. Take your best shot!
>
> 1) You need an explicit example of what virtual/jdk/jdk-1.4.ebuild looks
> like.

Will add.

> 2) For the consistency section, I'm not sure how you're going to
> implement this. The example I tend to use is this (versions simplified
> slightly for clarity):
>
> * User emerges vim-6.3, gvim-6.3. ~vim-core-6.3 is in as an RDEPEND.
> * User upgrades to vim-7.0. ~vim-7.0 is in as an RDEPEND.
> * User still has gvim-6.3 installed. gvim-6.3 has an RDEPEND upon
> ~vim-6.3, which is no longer installed. gvim is now broken.
>
> An example of exactly how portage would 'solve' this would be
> helpful. Would it ask for an unmerge of gvim-6.3 or would it include an
> upgrade of gvim-6.3 as part of the "emerge ~vim-7"?

Yep something like that. The specifics of what to do in various cases such as 
that one have not been worked out but are irrelevant to the glep anyway. The 
glep only need require that it is handled.

> 3) We don't specify every virtual in every profile thanks to cascades.

And...? I guess you are referring to "profiles must provide a default ..." but 
that _is_ a correct statement. If somebody wants to create a new profile that 
doesn't derive from base, they must specify defaults for all the virtuals.

> 4) Backwards compatibility -- all virtuals ebuilds should include
> DEPEND=">=portage-2.whatever" as well as the "|| ( foo bar )" stuff.

Why? The virtuals would be no different to regular packages.


Regards,
Jason Stubbs
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Virtuals revisited (Round 3)

[Ciaran McCreesh]

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

On Thu, 7 Apr 2005 23:53:38 +0900 Jason Stubbs <jstubbs@gentoo.org>
wrote:
| > An example of exactly how portage would 'solve' this would be
| > helpful. Would it ask for an unmerge of gvim-6.3 or would it include
| > an upgrade of gvim-6.3 as part of the "emerge ~vim-7"?
| 
| Yep something like that. The specifics of what to do in various cases
| such as  that one have not been worked out but are irrelevant to the
| glep anyway. The  glep only need require that it is handled.

Better to say *how* it would be handled IMO.

| > 3) We don't specify every virtual in every profile thanks to
| > cascades.
| 
| And...? I guess you are referring to "profiles must provide a default
| ..." but  that _is_ a correct statement. If somebody wants to create a
| new profile that  doesn't derive from base, they must specify defaults
| for all the virtuals.

Serves them right for not deriving from base :)

| > 4) Backwards compatibility -- all virtuals ebuilds should include
| > DEPEND=">=portage-2.whatever" as well as the "|| ( foo bar )" stuff.
| 
| Why? The virtuals would be no different to regular packages.

Oh, actually, it's worse than I thought. You can't use virtual/ as the
prefix *at all*.

ciaranm@snowdrop overlay 0 0.10 $ cat virtual/breakme/breame-1.ebuild
ciaranm@snowdrop overlay 0 0.09 $ cat app-misc/breakme/breakme-1.ebuild
DEPEND="virtual/breakme"
KEYWORDS="x86"
ciaranm@snowdrop overlay 1 0.05 $ FEATURES=-candy emerge
app-misc/breakme -pv

These are the packages that I would merge, in order:

Calculating dependencies -
!!! Cannot resolve a virtual package name to an ebuild.
!!! This is a bug, please report it. (virtual/breakme-1)

AFAIK, virtual can't be removed from categories either...

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Fluxbox, shell tools)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Virtuals revisited (Round 3)

[Jason Stubbs]

On Friday 08 April 2005 00:05, Ciaran McCreesh wrote:
> On Thu, 7 Apr 2005 23:53:38 +0900 Jason Stubbs <jstubbs@gentoo.org>
>
> wrote:
> | > An example of exactly how portage would 'solve' this would be
> | > helpful. Would it ask for an unmerge of gvim-6.3 or would it include
> | > an upgrade of gvim-6.3 as part of the "emerge ~vim-7"?
> |
> | Yep something like that. The specifics of what to do in various cases
> | such as  that one have not been worked out but are irrelevant to the
> | glep anyway. The  glep only need require that it is handled.
>
> Better to say *how* it would be handled IMO.

Yes, it is. But not in this GLEP.

> | > 3) We don't specify every virtual in every profile thanks to
> | > cascades.
> |
> | And...? I guess you are referring to "profiles must provide a default
> | ..." but  that _is_ a correct statement. If somebody wants to create a
> | new profile that  doesn't derive from base, they must specify defaults
> | for all the virtuals.
>
> Serves them right for not deriving from base :)

In other words, irrelevant.

> | > 4) Backwards compatibility -- all virtuals ebuilds should include
> | > DEPEND=">=portage-2.whatever" as well as the "|| ( foo bar )" stuff.
> |
> | Why? The virtuals would be no different to regular packages.
>
> Oh, actually, it's worse than I thought. You can't use virtual/ as the
> prefix *at all*.
>
> ciaranm@snowdrop overlay 0 0.10 $ cat virtual/breakme/breame-1.ebuild
> ciaranm@snowdrop overlay 0 0.09 $ cat app-misc/breakme/breakme-1.ebuild
> DEPEND="virtual/breakme"
> KEYWORDS="x86"
> ciaranm@snowdrop overlay 1 0.05 $ FEATURES=-candy emerge
> app-misc/breakme -pv
>
> These are the packages that I would merge, in order:
>
> Calculating dependencies -
> !!! Cannot resolve a virtual package name to an ebuild.
> !!! This is a bug, please report it. (virtual/breakme-1)
>
> AFAIK, virtual can't be removed from categories either...

Can fix this for portage-2.0.51.20.

Regards,
Jason Stubbs
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Virtuals revisited (Round 3)

[Ciaran McCreesh]

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

On Fri, 8 Apr 2005 00:17:32 +0900 Jason Stubbs <jstubbs@gentoo.org>
wrote:
| > | > 3) We don't specify every virtual in every profile thanks to
| > | > cascades.
| > |
| > | And...? I guess you are referring to "profiles must provide a
| > | default ..." but  that _is_ a correct statement. If somebody wants
| > | to create a new profile that  doesn't derive from base, they must
| > | specify defaults for all the virtuals.
| >
| > Serves them right for not deriving from base :)
| 
| In other words, irrelevant.

In other words, it's a pretty tame 'justification', especially when
there're far better ones. It's like saying that vim is better than nano
because the name is one character less to type in.

| > AFAIK, virtual can't be removed from categories either...
| 
| Can fix this for portage-2.0.51.20.

We're gonna need another one of those "all users *must* upgrade portage
to at least 2.0.51.20" notices? As soon as this gets implemented, anyone
who syncs with an old version of portage is screwed (hence my original
dep comment before I realised how nasty the error actually was).

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Fluxbox, shell tools)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Virtuals revisited (Round 3)

[Jason Stubbs]

On Friday 08 April 2005 00:24, Ciaran McCreesh wrote:
> On Fri, 8 Apr 2005 00:17:32 +0900 Jason Stubbs <jstubbs@gentoo.org>
> wrote:
> | > AFAIK, virtual can't be removed from categories either...
> |
> | Can fix this for portage-2.0.51.20.
>
> We're gonna need another one of those "all users *must* upgrade portage
> to at least 2.0.51.20" notices? As soon as this gets implemented, anyone
> who syncs with an old version of portage is screwed (hence my original
> dep comment before I realised how nasty the error actually was).

We're talking at least 12 months between 2.0.51.20 and a public version of 
portage implementing this GLEP. Specifically, looking at it for 2.2.0. So not 
only will it be in the latest stable release of two major versions back, 
there will also be a complete interim major version that will support it the 
whole way through.

Regards,
Jason Stubbs
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Virtuals revisited (Round 3)

[Jason Stubbs]

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

On Thursday 07 April 2005 22:20, Jason Stubbs wrote:
> Back in my quest to rid the tree of the evil virtuals and their plot to
> destroy my mind. I think I've covered all bases with this one - perhaps
> even enough to satisfy TGL. Take your best shot!

Replying to myself because I don't like deep deep threads. Anyway, updated 
based on the feedback received thus far.

Regards,
Jason Stubbs

[-- Attachment #2: virtuals-glep.txt --]
[-- Type: text/plain, Size: 7233 bytes --]

GLEP: XXX
Title: Virtuals Deprecation
Version: $Revision: 1.4 $
Last-Modified: $Date: 2003/07/19 12:09:20 $
Author:	Jason Stubbs <jstubbs@gentoo.org>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 06-May-2005
Post-History: 07-May-2005


Credits
=======

Most ideas in this GLEP came out of discussion with Thomas de Grenier de
Latour.  Ciaran McCreesh, Brian Harring and Stephen Bennett have also provided
help in fleshing out the idea.


Abstract
========

This GLEP covers the pitfalls of the current virtuals system, the benefits of
using regular ebuilds to serve the purpose of virtuals and what needs to be
supported to make it viable.


Motivation
==========

The current virtuals system is decentralized; that is there is no way to find
information about a specific virtual other than to scan all packages for what
they provide.  There is also no way to tell whether an atom is a virtual or
not - yes, the "virtual/" prefix could have been used but it isn't which has
led to its abuse.

What this means is that portage must scan all installed packages for the
virtuals they provide, that profiles must provide a default for every single
virtual that portage might encounter and that every single atom that portage
processes must be checked against the list of virtuals.  Needless to say that
this causes quite a performance decrease.

The current virtuals system also has some other major shortcomings.  The most
well known case is virtual/jdk and kaffe.  Kaffe-1.1.4 implements the Java 1.4
API but can not satisfy a package that requires >=virtual/jdk-1.4 because
kaffe's versioning scheme differs.  (ED: Need to add some more here. ;)


Specification
=============

This GLEP recommends that virtuals become no different to regular packages.
Specifically, the standard virtual would include the DESCRIPTION, KEYWORDS,
IUSE and RDEPEND metadata.  An example would be something like this:

::
	DESCRIPTION="Java Development Kit 1.4"
	KEYWORDS="amd64 hppa ia64 ppc ppc64 sparc x86"
	RDEPEND="|| (
	             =dev-java/blackdown-jdk-1.4\*
	             =dev-java/ibm-jdk-bin-1.4*
	             =dev-java/jrockit-jdk-bin-1.4*
	             =dev-java/kaffe-1.1.4*
	             =dev-java/sun-jdk-1.4*
	            )"
	IUSE=""

However, there are some issues that have been brought up with doing this.


Consistency
-----------

Presently, it is very easy to remove packages even if others are dependent
on them, which can lead to broken emerges when packages rely on indirect
dependencies.  For example, if kdelibs is merged bringing in qt and then
qt is unmerged, attempting to merge kdebase will likely fail.  This becomes
a much bigger problem with virtuals as packages because the dependencies
are always indirect.

The resolution for this issue will be to add full dependency tracking and
verification to portage.  The details of how it will be done are outside the
scope of this GLEP, but essentially this means that portage will need to be
forced to unmerge a package that is depended on by another and will also be
able to scan and fix any broken dependencies.


Overrides
---------

Profiles currently specify the default provider of each virtual and users are
able to override these defaults using /etc/portage/profile/virtuals.  If
virtuals are replaced by regular packages and thus able to have arbitrarily
complex DEPENDs, the current method of overriding default virtuals can not
be extended to support this.

Before looking at a solution, lets look at how the current system works.  When
portage initializes, it searches installed packages for available virtuals.
It then searches profiles and user overrides and adds them to the available
providers list and/or changes the order of the providers so that overrides are
listed earlier.  Portage then expands any virtual atom it finds into an OR
list using the order decided upon at initialization.

To keep this behaviour available, this GLEP proposes a new file named
package.prefer.  In its basic form, this is just a list of package names
ordered by preference.  Portage would use it by reordering the atoms of any
OR list it processes to fit the order given by package.prefer.  For example,
if package.prefer contained "dev-java/kaffe" then:

::
	
	|| (
	    dev-java/blackdown-jdk
	    dev-java/sun-jdk
	    dev-java/kaffe
	   )

would be processed as:

::
	
	|| (
	    dev-java/kaffe
	    dev-java/blackdown-jdk
	    dev-java/sun-jdk
	   )

In its basic form, package.prefer already covers profile and user overrides.
However, this GLEP proposes that any type of atom be usable.  This will be
accomplished by checking for intersections of the atoms in the OR list and
atoms in the preferred list.  When an intersection is found, both atoms
would be specified in a sublist, which would then be treated as a ranged dep.
For example, if package.prefer contained "<=dev-java/sun-jdk-1.4" then:

::
	
	|| (
	    >=dev-java/blackdown-jdk-1.3
	    >=dev-java/sun-jdk-1.3
	   )

would be processed as:

::
	
	|| (
	    (
	      <=dev-java/sun-jdk-1.4
	      >=dev-java/sun-jdk-1.3
	    )
	    >=dev-java/blackdown-jdk-1.3
	    >=dev-java/sun-jdk-1.3
	   )

Ranged deps are outside of the scope of this GLEP.


Rationale
=========

The number one advantage is that it offers more power to both the user and
the developer.  Flexibility of virtuals is far greater in this scheme and
fulfills requirements that exist already.  It also means that the maintainers
of profiles will not need to list a default for every virtual.  The user
benefits by being able to easily gather a list of providers of a virtual as
well as their control being extended to allow selection where there is a
choice within any package.

Portage code also benefits from this scheme as virtuals will no longer
require special handling or dual implementations of essentially the same
feature, for example USE-based PROVIDEs.  This scheme is also much easier to
optimize which will benefit the processing of all packages.  It also means
that any additions to the DEPEND vocabulary become available for use in the
definitions of virtuals.


Backwards Compatibility
=======================

Compatibility will begin by making 2.0.51.20 treat unknown virtuals like
regular packages.  When the tree is stripped of PROVIDEs and "virtuals"
override files, the only virtuals that these portages will use are those that
the user has specified and those gleaned from installed packages.  Any
unknown virtual will be treated like a regular package and looked for in the
tree.

The next major version of portage (2.1.0) will support consistency
checking.  The only remaining issue is that of user overrides.  The old
method will work even with new style virtuals.  The only catch is that
complex virtuals - that is virtuals that will install more than one package -
may not be overridable satisfactorally.

Dropping of support of current style virtuals is planned for the following
major version of portage (2.2.0).  When the time comes to release it, scripts
will be written to create packages from the existing virtuals system as well
as to create appropriate package.prefer overrides within the profiles.


Copyright
=========

This document has been placed in the public domain.

Re: [gentoo-dev] Virtuals revisited (Round 3)

[Paul de Vrieze]

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

On Thursday 07 April 2005 15:20, Jason Stubbs wrote:
> if package.prefer contained "dev-java/kaffe" then:
>
>
>         
>         || (
>             dev-java/blackdown-jdk
>             dev-java/sun-jdk
>             dev-java/kaffe
>            )
>
> would be processed as:
>
>
>         
>         || (
>             dev-java/kaffe
>             dev-java/blackdown-jdk
>             dev-java/sun-jdk
>            )

I think that even without this glep portage might be patched to sort or lists. 
Currently the first get picked. We might want to change that to preferring 
packages that do allready have an installed version above ones that don't.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Virtuals revisited (Round 3)

[Jason Stubbs]

On Friday 08 April 2005 19:48, Paul de Vrieze wrote:
> I think that even without this glep portage might be patched to sort or
> lists. Currently the first get picked. We might want to change that to
> preferring packages that do allready have an installed version above ones
> that don't.

This should be the case already. The first one should only be picked if there 
is nothing installed.

Regards,
Jason Stubbs
--
gentoo-dev@gentoo.org mailing list