g-cpan does not honor GCPAN_OVERLAY

[ostroffjh]

I have GCPAN_OVERLAY set to /usr/local/portage (my local overlay) in both make.conf and ~/.gcpanrc. That is the only overly my regular user has write privs for. I may have originally goten into trouble by running g-cpan as root, so it created a number of ebuilds in perl-gcpan under two different layman overlays. I deleted all of those (all were duplicates or rebuilt ebuilds already in the local overlay) but when I did "g-cpan -u" as my regular user, it eventually failed due to lack of write privs in one of the layman overlays. I'm not sure if this might be a configuration issue - but I note the man page says it honors repos.conf, but does not mention repos.conf.d, so I don't know if this related or not to Gentoo bug 581490.

[ostroffjh]

More info (after reviewing my old Gentoo bug) "g-cpan -lvd" output includes
$VAR2 = {
'DISTDIR' => '/usr/portage/tree/distfiles',
'PORTDIR_OVERLAY' => '/var/lib/layman/dotnet /var/lib/layman/shnurise /var/lib/layman/kde /usr/local/portage',
'ACCEPT_KEYWORDS' => 'amd64',
'GCPAN_CAT' => 'perl-gcpan',
'PORTDIR' => '/usr/portage/tree',
'GCPAN_OVERLAY' => '/usr/local/portage'
};

• OVERLAY: /usr/local/portage/perl-gcpan
  so it appears that the first item in PORTDIR_OVERLAY sometimes overrides GCPAN_OVERLAY for dothere g-cpan tries to put new ebuilds. The rest of that output does list all the ebuilds created by g-cpan. "g-cpan -uvdp" as my regular user still fails on not being able to create /var/lib/layman/dotnet/perl-gcpan.

[bor]

What version of g-cpan do you have?

[ostroffjh]

At the time I filed this it was 9999 (i.e., from git master) installed 28 May.

[ostroffjh]

I just updated, and when running as root, it created ebuilds in both the first and second and fourth dirs on PORTDIR_OVERLAY, which is unchanged from above. When I run as my regular user, it simply refuses to run with "* INSUFFICIENT PERMISSIONS TO RUN EMERGE" and that logic is simply wrong, since my local overlay has permissions set so I have full rights there. "g-cpan -g" seems to require a module name, and "g-cpan -ug" fails on permissions - but I should be able to create any ebuilds necessary for upgrades.

[leycec]

Seconded. I'm suffering similar hard blockers. g-cpan ignores the GCPAN_OVERLAY environment variable set in /etc/portage/make.conf:

$ grep GCPAN_OVERLAY /etc/portage/make.conf
GCPAN_OVERLAY=/home/leycec/bash/raiagent
$ g-cpan -g Test::Directory
 * The option you have chosen isn't supported without a configured overlay.

Shoot me fam. Of course, man g-cpan still claims that g-cpan respects this variable:

If you want to generate ebuilds to a specific overlay, you may set GCPAN_OVERLAY in your "make.conf", ".gcpanrc" or environment.

I have no idea what .gcpanrc is. I assume that's an undocumented dotfile in the standard Linux conf format expected to live at ~/.gcpanrc for the user running g-cpan, but... yeah.

In short, insufficient (and occasionally erroneous) documentation is arguably worse than no documentation at all. With respect to initial user experience (UX), g-cpan sadly leaves much to be desired.

This isn't a good look, guys. Japanese Ogre frowns fiercely. 👹

[leycec]

Just "Ugh!" I've now tried defining both a one-line ~/.gcpanrc file defining GCPAN_OVERLAY and an environment variable of the same name. Naturally, g-cpan insists on ignoring both:

$ echo 'GCPAN_OVERLAY=/home/leycec/bash/raiagent' >> ~/.gcpanrc
$ g-cpan -g Test::Directory              
 * The option you have chosen isn't supported without a configured overlay.
$ GCPAN_OVERLAY=/home/leycec/bash/raiagent
$ g-cpan -g Test::Directory              
 * The option you have chosen isn't supported without a configured overlay.

On the one hand, this project hasn't received a commit for nearly a year and is thus effectively dead; on the other hand, core functionality that probably never worked is advertised as working; on the gripping hand, this may not necessarily be a bad thing.
Perhaps defining Perl ebuilds manually without g-cpan is the correct approach, after all.

[leycec]

lolbro. I can confirm that g-cpan ignores GCPAN_OVERLAY but not PORTDIR_OVERLAY, despite going to excruciating extremes in /usr/bin/g-cpan to handle both.

Cursory inspection of /usr/bin/g-cpan suggests that GCPAN_OVERLAY handling is fundamentally broken indeed. Ideally, GCPAN_OVERLAY should be handled in the exact same way that PORTDIR_OVERLAY is handled. Instead, GCPAN_OVERLAY is currently handled with completely separate logic that fails hard. My uneducated recommendation is as follows:

• Remove the clearly broken $GCPAN_OVERLAY variable and all references to that variable.
• Augment the clearly working $overlay variable to support both the GCPAN_OVERLAY and PORTDIR_OVERLAY environment variables: e.g.,

# Instead of this...
my $overlay = $gcpan_run->getEnv('PORTDIR_OVERLAY');

# ...just do this.
my $overlay =
    $gcpan_run->getEnv('GCPAN_OVERLAY') or
    $gcpan_run->getEnv('PORTDIR_OVERLAY');

• Define new unit tests in t/ to make sure this never happens again. Please. Please, God. Because this is horrible and makes my face hurt.

[bor]

Thank you @leycec for uplift the topic.
It seems like you have the last stable g-cpan version which is old enough (honestly is very old).
Is not it?

I have to force myself to release a new version!

[ostroffjh]

I'm also still seeing the problems with a newly emerged 9999 version, so an update would be very welcome.

[bor]

As a workaround for now you can try this line in make.conf:

PORTDIR_OVERLAY="/path/to/gcpan_overlay $PORTDIR_OVERLAY"

[ostroffjh]

In make.conf I changed "PORTDIR="/usr/portage" to "PORTDIR="/usr/local/portage /usr/portage". g-cpan did say

• OVERLAY: /usr/local/portage/perl-gcpan
  but didn't actually create a new ebuild (the only one is actually up to date). However, after that, any use of emerge fails with:
  !!! Section 'gentoo' in repos.conf has location attribute set to nonexistent directory: '/usr/local/portage /usr/portage'
  !!! Invalid Repository Location (not a dir): '/usr/local/portage /usr/portage'
  WARNING: One or more repositories have missing repo_name entries:

  /usr/local/portage /usr/portage/profiles/repo_name

NOTE: Each repo_name entry should be a plain text file containing a
unique name for the repository on the first line.

Changing make .conf to two lines:
PORTDIR="/usr/portage"
PORTDIR="/usr/local/portage $PORTAGE"
makes g-cpan start with

• OVERLAY: /var/lib/layman/dotnet/perl-gcpan
• OVERLAY: /usr/local/portage/perl-gcpan
  and it puts the new ebuild in the dotnet overlay and emerge fails again with the first two lines above.

[bor]

@ostroffjh please note that there is a difference between PORTDIR and PORTDIR_OVERLAY.

You shouldn't change PORTDIR.

[ostroffjh]

Oh )(^&%^&*( my bad. I'll try the correct way and report back.

[ostroffjh]

Thanks. That seems to work OK. I did not already have any PORTDIR_OVERLAY. I still also have GCPAN_OVERLAY.

[bor]

The main idea to place the gcpan-overlay first in this list.

Anyway I will try to fix it in future versions.

[TerraTech]

Using PORTDIR_OVERLAY is deprecated and superseded by repos.conf

The way I worked around this issue, in order to use the modern repos.conf configuration method while keeping my make.conf clean, was adding PORTDIR_OVERLAY directly to ~/.gcpanrc.

Of note: .gcpanrc ignores GCPAN_OVERLAY=... but does respect PORTDIR_OVERLAY=...