Bug 919672 – app-portage/gentoopm does not respect PORTDIR_OVERLAY

• Product: Gentoo Linux
• Status: RESOLVED INVALID

[Description Hank Leininger 2023-12-09 21:29:46 UTC]

Maybe this is documented somewhere, but I couldn't find it.

I've had a local overlay since forever, listed in /etc/portage/make.conf:
PORTDIR_OVERLAY="/usr/local/portage-overlays"

For no good reason, that is actually a symlink to /usr/local/src/gentoo-portage-overlay. It contains a metadata/layout.conf, etc.

It seems like PORTDIR_OVERLAY is being phased out, but it still works fine for portage in general - emerge, and tools like portageq:

# portageq repos_config /
[DEFAULT]
...

[My-Overlay]
auto-sync = yes
location = /usr/local/src/gentoo-portage-overlay
masters = gentoo
...

[gentoo]
...

However, gentoopmq from gentoopm can't find it:
$ gentoopmq repo-path My-Overlay
usage: gentoopmq repo-path [-h] repo_name
gentoopmq repo-path: error: No repository named My-Overlay

This meant that tools like gpy-upgrade-impl from gpyutils could not find my overlay.

If I finally create an /etc/portage/repos.conf/ file and paste in the same contents from portageq output, it works fine:

$ gentoopmq repo-path My-Overlay
/usr/local/src/gentoo-portage-overlay

Again, maybe surprises nobody but me, since repos.conf/ entries are the preferred way now. But with gentoopm being a "wrapper for API of Gentoo package managers (Portage, ...", it seemed odd that it didn't behave the same way portage does.

[Comment 1 Michał Górny 2023-12-10 19:13:52 UTC]

gentoopm does not implement specific configuration features, it defers that to the package manager backend used.  If it doesn't work for you, then probably it isn't using the Portage backend for you.

[Comment 2 Mike Gilbert 2023-12-10 19:53:59 UTC]

Try setting PACKAGE_MANAGER=portage in the enivronment.

[Comment 3 Hank Leininger 2023-12-10 20:05:24 UTC]

(In reply to Michał Górny from comment #1)
> gentoopm does not implement specific configuration features, it defers that
> to the package manager backend used.  If it doesn't work for you, then
> probably it isn't using the Portage backend for you.

Hah, you are right, thanks! If I specify -p portage explicitly, it works.

Now that I know what I'm looking for, found it's documented that pkgcore does not respect PROTDIR_OVERLAY in make.conf (https://pkgcore.github.io/pkgcore/man/pkgcore.html)

Turns out I do have sys-apps/pkgcore installed on this box because it's a dep for tools like pkgcheck. I guess gentoopm prefers that if it's available. 

(In reply to Mike Gilbert from comment #2)
> Try setting PACKAGE_MANAGER=portage in the enivronment.

Tried that for science - works! And for tools like gpy-upgrade-impl that use gentoopm but don't have a comparable command-line flag, as well.

Of course, I should just propagate a repos.conf/ entry anyway, but this is good to know :)