On Thu, Jul 29, 2010 at 04:26:10PM -0300, Otttvio Pontes wrote:
>    On Tue, Jul 27, 2010 at 22:49, Brian Harring <[1]ferringb@gmail.com>
>    wrote:
>      The reason I ask is that an overlay literally stacks repositories,
>      slaves shadowing the master.  If you do an emerge
>      =dev-util/diffball-1.0 for the configuration above, you get local1's
>      ebuild, not gentoo's.  Repository atom's should not be able to
>      bypass
>      this- namely it violates the very nature of repository stacking.
> 
>    I see no reason to avoid this. Imagine if I use an overlay with some
>    kde ebuilds. But, for some reason, i want to install kcalc from
>    portage, and not from this overlay.
>    Portage has this versions of kcalc: 4.4.2 and 4.4.3.
>    And this overlay has the version: 4.4.3.
>    If i try to emerge kcalc::gentoo in multirepo-portage it will install
>    the kcalc-4.4.3, which is the newer version in portage.
>    I don't think it's a good idea to install kcalc-4.4.2, because version
>    4.4.3 is in an overlay too.

Bluntly, if you don't want overlay stacking semantics, do not 
configure it as an overlay then- configure the 'overlay' as a 
standalone repository and specify preferred ordering.

Literally, you're trying to make overlays standalone via this logic.  
You're trying to make overlays not *be* overlays.

The problem here is that PORTDIR_OVERLAY has historically forced 
overlay stacking- you can't just change the semantics of those rules 
and suddenly label them all as standalone, or create a quasi 
overlay/standalone repo.

The purpose of multi-repos at it's core is to add in standalone 
repositories- if people want those semantics for a repo, they 
configure the repo as a standalone.

~brian