Re: [gentoo-portage-dev] repos.conf location w.r.t PORTAGE_CONFIGROOT
On Thu, 2015-05-07 at 14:09 -0700, Zac Medico wrote:
On 05/07/2015 03:51 AM, Joakim Tjernlund wrote:
On Wed, 2015-05-06 at 22:45 +, Joakim Tjernlund wrote:
On Wed, 2015-05-06 at 15:16 -0700, Zac Medico wrote:
On 05/06/15 14:57, Joakim Tjernlund wrote:
On Wed, 2015-05-06 at 14:36 -0700, Zac Medico wrote:
On 05/06/15 14:30, Joakim Tjernlund wrote:
On Wed, 2015-05-06 at 13:30 -0700, Zac Medico wrote:
On 05/06/15 13:22, Joakim Tjernlund wrote:
On Wed, 2015-05-06 at 12:54 -0700, Zac Medico wrote:
On 05/06/15 12:41, Joakim Tjernlund wrote:
On Wed, 2015-05-06 at 19:13 +, Joakim Tjernlund wrote:
On Wed, 2015-05-06 at 11:37 -0700, Zac Medico wrote:
On 05/06/15 09:54, Joakim Tjernlund wrote:
I am trying to rebuild an old cross sysroot and I
got problems.
I cannot make emerge to select my old ebuilds in an
overlay over those
in /usr/portage.
What new is since last time I did this is
/etc/portage/repos.conf/
I suspect emerge always reads
/etc/portage/repos.conf/ no matter
what I set PORTAGE_CONFIGROOT / ROOT to ?
Jocke
It instantiates 2 config instances, one using
/etc/portage/repos.conf
(for build time DEPEND) and another one using
$PORTAGE_CONFIGROOT/etc/portage/repos.conf (for run
time {P,R}DEPEND).
You can see that it's joined with PORTAGE_CONFIGROOT
in the
load_repository_config function:
https://gitweb.gentoo.org/proj/portage.git/tree/pym/portage/repository/config.py?id=
0f19
11
13cc
cd04
9e11
fdbe
73
493eb1efbf4bf89e#n971
I see, doesn't this prevent exactly what I want to do?
I can't see why this should be needed, it only creates
a mess, another example:
I tried to specify exact version of my old binutils and
while that worked, portage
wanted
to pull in a newer binutils-config from the hosts
master gentoo repo and
thus the build failed.
If a someone really wants this behaviour, he can just
add the hosts master repo
in his PORTAGE_CONFIGROOT IMHO
Maybe emerge --root-deps=rdeps is what you are looking for.
This will
cause it to ignore DEPEND.
That is not the same is it? if I emerge ncurses it will
build ncurses but still
take the ebuild from the hosts master since it is newer
version.
I realize now that I can change what repos are searched by
using
PORTAGE_REPOSITORIES=/my/own/repos.conf/
but I still find the default behaviour very confusing and I
don't see that it is useful.
The idea is that you have separate repositories configured for
each
ROOT. If it's satisfying a build-time DEPEND that will be
installed into
ROOT=/, then it's supposed to use the repositories configured
for ROOT=/.
I see, but in my case I only install into my sysroot so I don't
want this behaviour.
So, why don't you use the --root-deps option?
Just did(and --root-deps=rdeps too) and it didn't work, still wants
to use
my newer hosts pkgs. :(
It shouldn't do that. It sounds like maybe the [gentoo] config
from/usr/share/portage/config/repos.conf is the source of your problems,
since you $PORTAGE_CONFIGROOT config will always inherit that. Would
that be consistent with your observations?
Moving that file out of the way changed things, now I got I profile error:
!!! Unable to parse profile: '/etc/portage/make.profile'
!!! ParseError: Parent 'gentoo:default/linux/amd64/13.0' not found:
'/var/lib/layman/transmode/profiles/gentoo64-server/parent'
!!! Your current profile is invalid. If you have just changed your profile
!!! configuration, you should revert back to the previous configuration.
!!! Allowed actions are limited to --help, --info, --search, --sync, and
!!! --version.
Which I think is a problem in my cross env.
No, this is not it. Portage just bails when reading the host profile which
it should not.
Note: defining
PORTAGE_REPOSITORIES=/my/own/repos.conf
gives the same error.
According to the error message, your transmode profile inherits a gentoo
profile, so you need the gentoo repository (at least the relevant profile).
I have a my own profile in
Re: [gentoo-portage-dev] repos.conf location w.r.t PORTAGE_CONFIGROOT
On 05/07/2015 11:43 PM, Joakim Tjernlund wrote:
On Thu, 2015-05-07 at 14:09 -0700, Zac Medico wrote:
On 05/07/2015 03:51 AM, Joakim Tjernlund wrote:
On Wed, 2015-05-06 at 22:45 +, Joakim Tjernlund wrote:
On Wed, 2015-05-06 at 15:16 -0700, Zac Medico wrote:
On 05/06/15 14:57, Joakim Tjernlund wrote:
On Wed, 2015-05-06 at 14:36 -0700, Zac Medico wrote:
On 05/06/15 14:30, Joakim Tjernlund wrote:
On Wed, 2015-05-06 at 13:30 -0700, Zac Medico wrote:
On 05/06/15 13:22, Joakim Tjernlund wrote:
On Wed, 2015-05-06 at 12:54 -0700, Zac Medico wrote:
On 05/06/15 12:41, Joakim Tjernlund wrote:
On Wed, 2015-05-06 at 19:13 +, Joakim Tjernlund wrote:
On Wed, 2015-05-06 at 11:37 -0700, Zac Medico wrote:
On 05/06/15 09:54, Joakim Tjernlund wrote:
I am trying to rebuild an old cross sysroot and I got problems.
I cannot make emerge to select my old ebuilds in an overlay
over those
in /usr/portage.
What new is since last time I did this is
/etc/portage/repos.conf/
I suspect emerge always reads /etc/portage/repos.conf/ no matter
what I set PORTAGE_CONFIGROOT / ROOT to ?
Jocke
It instantiates 2 config instances, one using
/etc/portage/repos.conf
(for build time DEPEND) and another one using
$PORTAGE_CONFIGROOT/etc/portage/repos.conf (for run time
{P,R}DEPEND).
You can see that it's joined with PORTAGE_CONFIGROOT in the
load_repository_config function:
https://gitweb.gentoo.org/proj/portage.git/tree/pym/portage/repository/config.py?id=
0f19
11
13cc
cd04
9e11
fdbe
73
493eb1efbf4bf89e#n971
I see, doesn't this prevent exactly what I want to do?
I can't see why this should be needed, it only creates a mess,
another example:
I tried to specify exact version of my old binutils and while
that worked, portage
wanted
to pull in a newer binutils-config from the hosts master gentoo
repo and
thus the build failed.
If a someone really wants this behaviour, he can just add the
hosts master repo
in his PORTAGE_CONFIGROOT IMHO
Maybe emerge --root-deps=rdeps is what you are looking for. This
will
cause it to ignore DEPEND.
That is not the same is it? if I emerge ncurses it will build
ncurses but still
take the ebuild from the hosts master since it is newer version.
I realize now that I can change what repos are searched by using
PORTAGE_REPOSITORIES=/my/own/repos.conf/
but I still find the default behaviour very confusing and I don't
see that it is useful.
The idea is that you have separate repositories configured for each
ROOT. If it's satisfying a build-time DEPEND that will be installed
into
ROOT=/, then it's supposed to use the repositories configured for
ROOT=/.
I see, but in my case I only install into my sysroot so I don't want
this behaviour.
So, why don't you use the --root-deps option?
Just did(and --root-deps=rdeps too) and it didn't work, still wants to
use
my newer hosts pkgs. :(
It shouldn't do that. It sounds like maybe the [gentoo] config
from/usr/share/portage/config/repos.conf is the source of your problems,
since you $PORTAGE_CONFIGROOT config will always inherit that. Would
that be consistent with your observations?
Moving that file out of the way changed things, now I got I profile error:
!!! Unable to parse profile: '/etc/portage/make.profile'
!!! ParseError: Parent 'gentoo:default/linux/amd64/13.0' not found:
'/var/lib/layman/transmode/profiles/gentoo64-server/parent'
!!! Your current profile is invalid. If you have just changed your profile
!!! configuration, you should revert back to the previous configuration.
!!! Allowed actions are limited to --help, --info, --search, --sync, and
!!! --version.
Which I think is a problem in my cross env.
No, this is not it. Portage just bails when reading the host profile which
it should not.
Note: defining
PORTAGE_REPOSITORIES=/my/own/repos.conf
gives the same error.
According to the error message, your transmode profile inherits a gentoo
profile, so you need the gentoo repository (at least the relevant profile).
I have a my own profile in PORTAGE_CONFIGROOT which does not
reference the host /etc/portage/make.profile at all so I think
portage is using the wrong profile.
When using ROOT=/foo, it always instantiates 2 profiles, and it uses one
profile for ROOT=/foo and the other profile for ROOT=/.
Futhermore, it does not understand the host profile, probably
because my own PORTAGE_CONFIGROOT don't have profile-formats = portage-2
You're saying this beciase of the above ParseError? I think maybe what
you want to do keep the default /usr/share/portage/config/repos.conf and
mask */*::gentoo in $PORTAGE_CONFIGROOT/etc/portage/package.mask.
--
Thanks,
Zac
[gentoo-portage-dev] [PATCH] VdbMetadataDelta.applyDelta: handle remove events properly (bug 547532)
Since commit d800d224ab38c0f524d3fe858ebe201cbfa903c1, emerge --search
could report removed packages as installed, since applyDelta failed to
apply remove events unless the cpv exactly matched. Fix it to apply
the remove event to each affected package slot, using the same code
which is used to handle replaced packages for add events.
Fixes: d800d224ab38 (Log changes between vdb_metadata.pickle updates)
X-Gentoo-Bug: 547532
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=547532
---
pym/portage/dbapi/_VdbMetadataDelta.py | 39 ++
1 file changed, 21 insertions(+), 18 deletions(-)
diff --git a/pym/portage/dbapi/_VdbMetadataDelta.py
b/pym/portage/dbapi/_VdbMetadataDelta.py
index 2dbb07a..7461f87 100644
--- a/pym/portage/dbapi/_VdbMetadataDelta.py
+++ b/pym/portage/dbapi/_VdbMetadataDelta.py
@@ -139,12 +139,12 @@ class VdbMetadataDelta(object):
def applyDelta(self, data):
packages = self._vardb._aux_cache[packages]
- added_slots = {}
+ deltas = {}
for delta in data[deltas]:
cpv = delta[package] + - + delta[version]
+ deltas[cpv] = delta
event = delta[event]
if event == add:
- added_slots[cpv] = delta
# Use aux_get to populate the cache
# for this cpv.
if cpv not in packages:
@@ -155,19 +155,22 @@ class VdbMetadataDelta(object):
elif event == remove:
packages.pop(cpv, None)
- # Remove replaced versions from updated slots
- for cached_cpv, (mtime, metadata) in list(packages.items()):
- if cached_cpv in added_slots:
- continue
- replaced = False
- for cpv, delta in added_slots.items():
- if (cached_cpv.startswith(delta[package]) and
- metadata.get(SLOT) == delta[slot]
and
- cpv_getkey(cached_cpv) ==
delta[package]):
- replaced = True
- break
- if replaced:
- del packages[cached_cpv]
- del added_slots[cpv]
- if not added_slots:
- break
+ if deltas:
+ # Delete removed or replaced versions from affected
slots
+ for cached_cpv, (mtime, metadata) in
list(packages.items()):
+ if cached_cpv in deltas:
+ continue
+
+ removed = False
+ for cpv, delta in deltas.items():
+ if
(cached_cpv.startswith(delta[package]) and
+ metadata.get(SLOT) ==
delta[slot] and
+ cpv_getkey(cached_cpv) ==
delta[package]):
+ removed = True
+ break
+
+ if removed:
+ del packages[cached_cpv]
+ del deltas[cpv]
+ if not deltas:
+ break
--
2.3.5
