| Summary: | perllocal.pod clash from multiple different packages | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | jonathan.yong |
| Component: | configuration | Assignee: | Tim Orling <tim.orling> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium+ | CC: | randy.macleod, ross.burton |
| Version: | unspecified | ||
| Target Milestone: | 2.8 M4 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | Yes (doc changes required) | |
If something is using cpan.bbclass it won't install the fiel, so any recipe that ships it is doing so explicitly for some reason. I believe we should add a QA test for this, but not wipe it out globally. Patch for the QA test on the list now. QA sanity test was merged in Zeus: a5a5708dbbb534f6624fafe9e78f96de25c10dea Individual recipes (from layers that are not triaged by the YP Bug Triage team) may still need to be corrected to not install perllocal.pod. If so, either send a patch to the proper mailing list to fix the recipe in question or send an email to the proper list highlighting the need to fix perllocal.pod QA test. |
Background: perl modules when installed can produce a perllocal.pod file for documenting a list of locally installed perl modules. This can conflict if multiple packages generate the file. When building lmsensors, it fails with: mc:x86:lmsensors-3.4.0-r0 do_prepare_recipe_sysroot: The file /usr/lib64/perl5/5.28.1/x86_64-linux/perllocal.pod is installed by both apparmor and rrdtool, aborting Should this file be removed automatically? I am using this bbclass as a workaround: remove_perllocal(){ if [ -d "${D}/${libdir}/perl5" ]; then find "${D}/${libdir}/perl5" -type f -name perllocal.pod -delete fi } do_install[postfuncs] += "remove_perllocal"