gentoo-perl / g-cpan Goto Github PK

g-cpan currently generates EAPI 5-compliant ebuilds. That's not necessarily the worst thing that's ever happened. Still, it would be strongly preferable if g-cpan generated EAPI 7-compliant ebuilds instead. EAPI 5 is over six years old and increasingly unsupported across various eclasses – thankfully excluding the perl-module eclass, of course!

Thanks as always for all the CPAN automation, fearless g-cpan crew.

The ebuild created by g-cpan has MODULE_VERSION=0.3.2, but the tarbal unpacks to File-Find-Object-v0.3.2, so the emerge chokes. Manually removing the "v" from the source folder allows me to manually go through the remaining ebuild steps, but a full emerge will never work. I don't know if there is actually anything that g-cpan can do - or if this is a naming problemin the CPAN tarball.

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.

Ebuilds autogenerated by g-cpan fail repoman checks... badly. This is bad, because many third-party overlays – including mine – internally run repoman under Travis CI to automatically validate the sanity and correctness of incoming pull requests.

Of course, g-cpan breaks that. For example, here's the litany of complaints for a recently generated Test::Directory ebuild:

$ repoman

RepoMan scours the neighborhood...
>>> Creating Manifest for /home/leycec/bash/raiagent/dev-perl/Test-Directory

  KEYWORDS.unsorted             1
   dev-perl/Test-Directory/Test-Directory-0.051.ebuild contains unsorted keywords
  dependency.bad [fatal]        12
   dev-perl/Test-Directory/Test-Directory-0.051.ebuild: DEPEND: alpha(default/linux/alpha/17.0)
['dev-perl/Test-Exception', 'dev-lang/perl', 'dev-lang/perl:=[-build(-)]']
   dev-perl/Test-Directory/Test-Directory-0.051.ebuild: RDEPEND: alpha(default/linux/alpha/17.0)
['dev-lang/perl:=[-build(-)]']
   dev-perl/Test-Directory/Test-Directory-0.051.ebuild: DEPEND: alpha(default/linux/alpha/17.0/desktop)
['dev-perl/Test-Exception', 'dev-lang/perl', 'dev-lang/perl:=[-build(-)]']
   dev-perl/Test-Directory/Test-Directory-0.051.ebuild: RDEPEND: alpha(default/linux/alpha/17.0/desktop)
['dev-lang/perl:=[-build(-)]']
   dev-perl/Test-Directory/Test-Directory-0.051.ebuild: DEPEND: alpha(default/linux/alpha/17.0/desktop/gnome)
['dev-perl/Test-Exception', 'dev-lang/perl', 'dev-lang/perl:=[-build(-)]']
   dev-perl/Test-Directory/Test-Directory-0.051.ebuild: RDEPEND: alpha(default/linux/alpha/17.0/desktop/gnome)
['dev-lang/perl:=[-build(-)]']
   dev-perl/Test-Directory/Test-Directory-0.051.ebuild: DEPEND: alpha(default/linux/alpha/17.0/desktop/gnome/systemd)
['dev-perl/Test-Exception', 'dev-lang/perl', 'dev-lang/perl:=[-build(-)]']
   dev-perl/Test-Directory/Test-Directory-0.051.ebuild: RDEPEND: alpha(default/linux/alpha/17.0/desktop/gnome/systemd)
['dev-lang/perl:=[-build(-)]']
   dev-perl/Test-Directory/Test-Directory-0.051.ebuild: DEPEND: alpha(default/linux/alpha/17.0/developer)
['dev-perl/Test-Exception', 'dev-lang/perl', 'dev-lang/perl:=[-build(-)]']
   dev-perl/Test-Directory/Test-Directory-0.051.ebuild: RDEPEND: alpha(default/linux/alpha/17.0/developer)
['dev-lang/perl:=[-build(-)]']
   dev-perl/Test-Directory/Test-Directory-0.051.ebuild: DEPEND: riscv(default/linux/riscv/17.0/rv64gc)
['dev-perl/Test-Exception', 'dev-lang/perl', 'dev-lang/perl:=[-build(-)]']
   dev-perl/Test-Directory/Test-Directory-0.051.ebuild: RDEPEND: riscv(default/linux/riscv/17.0/rv64gc)
['dev-lang/perl:=[-build(-)]']
  ebuild.badheader              1
   dev-perl/Test-Directory/Test-Directory-0.051.ebuild: line 3: Non-blank line after header
  ebuild.minorsyn               1
   dev-perl/Test-Directory/Test-Directory-0.051.ebuild: line 10: Useless blank line
  ebuild.notadded               1
   dev-perl/Test-Directory/Test-Directory-0.051.ebuild
  metadata.missing [fatal]      1
   dev-perl/Test-Directory/metadata.xml

Note: use --include-dev (-d) to check dependencies for 'dev' profiles

Please fix these important QA issues first.
RepoMan sez: "Make your QA payment on time and you'll never see the likes of me."

The fatal keyword issues are clearly the worst. Ideally, g-cpan should only add keywords that are actually supported. In this case, removing alpha and riscv from the KEYWORDS variable in the autogenerated Test-Directory-0.051.ebuild file temporarily solves the issue – but only until the next g-cpan -u. <mournful_sigh/>

Likewise, a trivial metadata.xml file should also be autogenerated: e.g.,

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd">
<pkgmetadata>
	<maintainer type="project">
		<email>[email protected]</email>
		<name>g-cpan</name>
	</maintainer>
</pkgmetadata>

The remaining complaints are non-fatal and hopefully trivial to solve. Thanks again for all the thankless volunteerism, stalwart g-cpan heroes! ⚔️

It's also allow to keep a correct perl version from which module comes and will be deprecated.
And allow put those dependencies into a generated ebuild.

For example (from #23):
OWL-Simple -> FAILS (due the package does not contain a OWL::Simple module).

These got renamed this week:

dev-perl     text-template                Text-Template
dev-perl     text-wrapper                 Text-Wrapper
dev-perl     tie-encryptedhash            Tie-EncryptedHash
dev-perl     yaml                         YAML

https://metacpan.org/diff/file?target=KENTNL%2FGentoo-Util-VirtualDepend-0.003015%2F&source=KENTNL%2FGentoo-Util-VirtualDepend-0.003014%2F

Just a TODO. Check how version is sanitized inside g-cpan and implement it in proper way, so g-cpan generated ebuilds will be more suitable for upstreaming.

Portage has deprecated the use of PORTDIR_OVERLAY in favor of the repos.conf method of configuring overlays. g-cpan doens't seem to handle this change.

# g-cpan -l 2>/dev/null
 * The option you have chosen isn't supported without a configured overlay.

As '@kentfredric' has mentioned and I totally agree.
The correct build workflow should be:

Check out code
Run perl Makefile.PL
Run make manifest
Run make dist

So need some fixes for this.

See disscussion at pull request #7

Were was a huge move(rename) for perl packages in 1Q-2016, to use proper names.
And this is a good update :)
But we need to keep a list of 'non-proper' names up-to-date, in g-cpan (Gentoo::Portage).

https://bugs.gentoo.org/show_bug.cgi?id=578678

https://bugs.gentoo.org/show_bug.cgi?id=561834

When generating an ebuild for the Iterator module, g-cpan incorrectly determines that it's part of the core perl install:

$ g-cpan -g Iterator
 * Iterator is part of the core perl install

This is because TAP::Parser::Iterator is part of perl core and the code for determining core membership only cares about the basename of the package and not the full path. After editing g-cpan to skip this check, the ebuild generates fine.

This will allow:

• to support the Gentoo Prefix Project
• to help in tests (to detach from real paths)

At the moment there is hardcore setting in one place, but in other it seems to support well.
Need a some kind of detection of the EROOT value.

There are cases when we need to update all generated ebuilds.

1. perl was updated, so corelist was changed, need to update deps, etc
2. gentoo policy, for example min requiring for EAPI was updated (gentoo #523458)

New option: --force? --update-force? --force-update?

Workarounds:

source /etc/make.conf && rm -r $GCPAN_OVERLAY/perl-gcpan/* && g-cpan -gu `qlist -I perl-gcpan/ | sed 's|perl-gcpan/||'`

source /etc/make.conf && find $GCPAN_OVERLAY/perl-gcpan -name '*.ebuild' -exec rm '{}' + && g-cpan -gu

As a most used, at CPAN especially

https://metacpan.org/release/CPAN-Changes
https://metacpan.org/pod/distribution/CPAN-Changes/lib/CPAN/Changes/Spec.pod

My current profile is provided by an overlay and has a parent file:

gentoo:default/linux/amd64/17.0

This works fine with portage, inheriting the profile default/linux/amd64/17.0 from the gentoo repo.

However, when I try to do anything with g-cpan-9999 it errors out:

~ # g-cpan -l
Error resolving realpath on '/usr/local/portage/overlays/tecknicaltom/profiles/default/linux/amd64/17.0/tecknicaltom/gentoo:default/linux/amd64/17.0': No such file or directory at /usr/lib64/perl5/vendor_perl/5.26.2/Gentoo/Portage/Q.pm line 153.

The code in _portage_env_files does not seem to handle the case of repo:path in parent profiles.

another TODO

$ bin/g-cpan -l
Use of uninitialized value $[1] in read at /usr/lib64/perl5/5.18.2/x86_64-linux-thread-multi/IO/Handle.pm line 463.
Use of uninitialized value $[1] in read at /usr/lib64/perl5/5.18.2/x86_64-linux-thread-multi/IO/Handle.pm line 463.

Meanwhile I was trying to generate an ebuild for OWL::Simple::Parser module, the digestion phase failed because g-cpan used as version number the one from the module (1.01) instead of the one from the whole Perl package (0.51) which contains it, as you can see at http://cpansearch.perl.org/src/TOMASZ/OWL-Simple-0.51/META.json

So, all these commands generate wrong ebuilds:

• g-cpan -g OWL::Simple::Parser -> FAILS (misuses version 1.01 instead of 0.51)
• g-cpan -g OWL::Simple::OBOWriter -> FAILS (misuses version 0.06 instead of 0.51)
• g-cpan -g OWL-Simple -> FAILS (due the package does not contain a OWL::Simple module)

I tested this with g-cpan 0.16.6 and master version, with the same results.