g-cpan's People
g-cpan's Issues
[Feature Request] EAPI 7 support
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.
handling 'v' in version string (problem building File::Find::Object)
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.
g-cpan does not honor GCPAN_OVERLAY
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.
Resolve "repoman" complaints
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!
Add Module::CoreList for check is module shipped with perl core
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.
Support handling of package names (as well as modules names)
For example (from #23):
OWL-Simple -> FAILS (due the package does not contain a OWL::Simple module)
.
Non-common package's names: 4 more removals
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
Add Kent's Gentoo::PerlMod::Version library for version sanitization.
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.
g-cpan doesn't work without PORTDIR_OVERLAY (using repos.conf)
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.
fixes for the build process
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
update list of 'converted packages names' (gentoo #578678)
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).
Need to care about version requirements in dependancies (gentoo #561834)
Incorrect "part of core perl install" detection
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.
handle EROOT in Portage::Q (detection and handling)
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.
Add option to update ebuilds forcibly (--force?)
There are cases when we need to update all generated ebuilds.
perl
was updated, so corelist was changed, need to update deps, etc- 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
Add the PortageXS as an interface to get portage information (env vars, ebuild, etc)
Migration from ChangeLog to Changes
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
Q.pm doesn't handle parent repos in different repos
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.
avoid warnings messages (from Shell::EnvImporter)
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.
Fails on packages there is mismatching between module & package versions
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.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.