/etc/portage/repos.conf is the new way of configuring repositories for Portage. PORTDIR and PORTDIR_OVERLAY variables in /etc/portage/make.conf are deprecated. euse should use portageq (or Portage's Python API) to get paths of repositories. $ euse ERROR: /usr/portage/profiles does not exist or is not a directory $ cat /etc/portage/repos.conf [DEFAULT] main-repo = gentoo [gentoo] location = /var/repositories/gentoo-x86 [local] location = /var/repositories/local priority = 0 $ grep PORTDIR /etc/portage/make.conf $ portageq portdir /var/repositories/gentoo-x86 $ portageq get_repos / local gentoo $ portageq get_repo_path / gentoo /var/repositories/gentoo-x86 $ portageq get_repo_path / local /var/repositories/local
I know repos.conf has been around for a few years. BUT! I have seen no deprecation notice for the old variables in either gentoo-portage-dev or gentoo-dev mail lists announcing the plan to deprecate them. There are many more tools out there that depend on those old variables. They are long established variables. Some tools modify those variables. It cannot just disappear without adequate notice and suitable replacement api's in place. Or a great many users systems/tools will break. I need more info about this plan, it's usability and api's before any work is done. Zac what is the plan for this? If this is to take place. I would think that a move such as this would require a 1 year minimum for tools to migrate to the new system, possibly longer. In my opinion this bug is premature. Downgrading to enhancement
(In reply to Brian Dolbec from comment #1) Old variables are currently only deprecated. There is no plan to make them stop working soon. Deprecation notice for old variables could be announced when tools like euse, eix and layman are made compatible with repos.conf-only configuration.
(In reply to Brian Dolbec from comment #1) > Zac what is the plan for this? If this is to take place. I would think > that a move such as this would require a 1 year minimum for tools to migrate > to the new system, possibly longer. Yes, there's plenty of time. Anyway, I think it would be good for euse to migrate to using portageq instead of parsing make.conf itself. Portage automatically generates PORTDIR and PORTDIR_OVERLAY variables from repos.conf settings (accessible with 'portageq envvar' command). Meanwhile, the problem with euse it that its get_portdir() function tries to parse the value from make.conf instead of using portageq, even though it already uses portageq for other things.
I will create a patch, which will also make euse faster with new versions of Portage (by using `portageq envvar -v EPREFIX PORTAGE_REPOSITORIES USE` instead of 4 calls to portageq).
This is now quite annoying since >=portage-2.2_alpha189 made repos.conf the default: # euse -i natspec ERROR: $PORTDIR couldn't be determined
(In reply to Lars Wendler (Polynomial-C) from comment #5) > This is now quite annoying since >=portage-2.2_alpha189 made repos.conf the > default: > > # euse -i natspec > ERROR: $PORTDIR couldn't be determined As a workaround, set PORTDIR="/usr/portage" in make.conf.
*** Bug 505160 has been marked as a duplicate of this bug. ***
Created attachment 423280 [details] euse -i natspec (In reply to Zac Medico from comment #6) > (In reply to Lars Wendler (Polynomial-C) from comment #5) > > This is now quite annoying since >=portage-2.2_alpha189 made repos.conf the > > default: > > > > # euse -i natspec > > ERROR: $PORTDIR couldn't be determined > > As a workaround, set PORTDIR="/usr/portage" in make.conf. WFM (see attachment) with =sys-apps/portage without that hack in make.conf This bug should be closed.
should be closed, WFM
*** This bug has been marked as a duplicate of bug 505160 ***
