I have two overlays set, one of them the CVS repo gentoo-x86 and one of them a local one. When I call PORTDIR=gentoo-x86 PORTDIR_OVERLAY='' emerge ... ebuilds from the local overlay should not be considered, yet they are. [ebuild R ~] sys-apps/portage-2.2.18::gentoo USE="(ipc) xattr -build -doc -epydoc -selinux" LINGUAS="-ru" PYTHON_TARGETS="python2_7 python3_3 python3_4 -pypy" 0 KiB
The same applies when I set PORTDIR_OVERLAY=/dev/null.
PORTDIR and PORTDIR_OVERLAY are in the process of being deleted. Permanent configuration of repositories is now in repos.conf. Configuration of repositories can be overridden by PORTAGE_REPOSITORIES variable. Example: PORTAGE_REPOSITORIES=$'[gentoo]\nlocation = /some/path\n[another_repository]\nlocation = /another/path' emerge ...
We need a sane replacement. Like a variable that overrides all repositories by paths, with Portage reading repo_name itself.
What if we add a repo based repos.conf that can be used as a backup for the missing information like portage does now for the main repo. So, the order would be, read /etc/portage/repos.conf/, failing that, check the repo for .../profiles/repos.conf, failing that /usr/share/portage/config/repos.conf. That way a simple path override should work using data from the repo's backup conf.
(In reply to Brian Dolbec from comment #4) > What if we add a repo based repos.conf that can be used as a backup for the > missing information like portage does now for the main repo. > > So, the order would be, read /etc/portage/repos.conf/, failing that, check > the repo for .../profiles/repos.conf, failing that > /usr/share/portage/config/repos.conf. > > > That way a simple path override should work using data from the repo's > backup conf. That seems like a chicken and egg problem. Under that scheme, how does the PM know where the repo is when it's not configured anywhere in the system? Personally, I'd prefer something like PORTAGE_REPOS="/path/to/repo1 /path/to/repo2" emerge ... (mostly because I've already implemented something similar). ;) I'm not sure we need to support setting all the various repos.conf settings for this use case. The priority/weight of the repos could be implicitly determined by the order of the listed repo paths in PORTAGE_REPOS and the repo_ids could be just pulled from the relevant files in the repo.
(In reply to Tim Harder from comment #5) > (In reply to Brian Dolbec from comment #4) > > What if we add a repo based repos.conf that can be used as a backup for the > > missing information like portage does now for the main repo. > > > > So, the order would be, read /etc/portage/repos.conf/, failing that, check > > the repo for .../profiles/repos.conf, failing that > > /usr/share/portage/config/repos.conf. > > > > > > That way a simple path override should work using data from the repo's > > backup conf. > > That seems like a chicken and egg problem. Under that scheme, how does the > PM know where the repo is when it's not configured anywhere in the system? Unless you're saying a combination of something like PORTAGE_REPOS and adding that file to a repo. That's viable I guess.
Yeah, that way if the repo had other settings like sync-type and sync-url, they could be synced, etc... But yes, primarily PORTAGE_REPOS provides the path to the repos for basic use. Any extra configs would be provided by the repo's repos.conf if it exists, or errors for those extra operations like sync.
