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

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

[Otávio Pontes]

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

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.*.
I also implemented support for syncing portage tree for several version
control systems (git, svn, darcs, hg, bzr, ) and changed emerge --sync to
sync all repositories in repos.conf with SYNC variable set. Its possible to
sync just one repository using emerge --sync repo_name. It's possible to
select which vcs will be used in SYNC variable, using the protocol in uri.
If you want to download from a git repo using http you can use: SYNC=git+
http://servername/repo.git.
After that i wrote a test in pym/portage/tests to use some provided ebuilds
to check if emerge is selecting the correct repository when using
::repository syntax. I am working now in improving this tests and writing
tests for package.* files and syncing.

That's all,
Otávio Pontes

[-- Attachment #2: Type: text/html, Size: 1333 bytes --]

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

[Brian Harring]

[-- 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 --]

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

[Otávio Pontes]

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

On Tue, Jul 27, 2010 at 22:49, Brian Harring <ferringb@gmail.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
>

[-- Attachment #2: Type: text/html, Size: 4117 bytes --]

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

[Brian Harring]

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

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

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