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

[Otávio Pontes]

On Tue, Jul 27, 2010 at 22:49, Brian Harring <ferringb@×××××.com> wrote:

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

Actually multirepo-portage is working different. If you try to
emerge =dev-util/diffball-1.0, it will use the ebuild from local1.
emerge =dev-util/diffball-1.0::local1 will do the same. But if you run
emerge =dev-util/diffball-1.0::gentoo, it will use the ebuild from gentoo
repository.


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

The same happens here. emerge dev-util/bsdiff-1.1::local1 will match and
will get the ebuild from local1.


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

And what about keywords/masks? Using your example, if a user adds in
package.mask:
dev-util/diffball::local1
I will mask all diffball ebuilds for local1. So emerge =diffball-1.0::gentoo
is suppose to fail too?


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