Re: [gentoo-soc] Multiple Repository Support in Portage - Report

[Brian Harring <ferringb@gmail.com>]

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

On Tue, Jul 27, 2010 at 12:56:44PM -0300, Otttvio Pontes wrote:
>    Hi,
> 
>    I have been some time without reporting my work at this mailing list
>    and i will send my report for the last weeks.
> 
>    When i sent my last e-mail I was working on emerging a package from one
>    specific repository using emerge package::repository syntax. It is now
>    working. It's possible to use the ::repository syntax in emerge command
>    line, ebuild dependencies and when masking/unmasking/setting use flags
>    in /etc/portage/package.*.

Just verifying- if you have repository configuration equivalent to the 
following

overlay stacking:
	master: /usr/portage: repo id gentoo
		has dev-util/diffball-1.0
        slave:  /usr/local/overlay1: repo id local1
		has dev-util/diffball-1.0
		has dev-util/bsdiff-1.1
	slave:  /usr/local/overlay2: repo id local2
		has dev-util/bsdiff-1.1

generated from a make.conf being
PORTDIR=/usr/portage
PORTDIR_OVERLAY="/usr/local/overlay1 /usr/local/overlay2"

For such a setup, =dev-util/diffball-1.0 is only visible from the 
local1 repo- specifically, emerge =dev-util/diffball-1.0::gentoo will 
not find the package, emerge =dev-util/diffball-1.0::local1 however 
will.

Further, =dev-util/bsdiff-1.1::local2 will match, but 
dev-util/bsdiff-1.1::local1 will not.

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.

So... what's the status of multirepo support's repository atom's for 
this case?
~brian

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