Bug 15563

Summary: Building a recipe that inherits cpan-base creates an image runtime dependency on perl
Product: [Build System, Metadata & Runtime] OE-Core Reporter: Barry G <mr.scada>
Component: oe-core otherAssignee: Barry G <mr.scada>
Status: RESOLVED INVALID QA Contact:
Severity: minor    
Priority: Medium+ CC: randy.macleod, ross.burton, tim.orling
Version: 5.0   
Target Milestone: 5.1 M3   
Hardware: x86   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: No (bug/feature does not impact docs)
Attachments:
Description Flags
Patch to break hard runtime dependency on perl none

Description Barry G 2024-07-24 15:06:34 UTC 
Created attachment 5061 [details]
Patch to break hard runtime dependency on perl

Hello,

I build an image with Postgresql in it via the meta-openembedded recipe:
https://github.com/openembedded/meta-openembedded/blob/scarthgap/meta-oe/recipes-dbs/postgresql/postgresql.inc#L40
said recipe inherits cpan-base.

cpan-base.bbclass (https://git.yoctoproject.org/poky/tree/meta/classes-recipe/cpan-base.bbclass?h=scarthgap#n14) adds
an RDEPEND for perl to the non-native package. This results in perl being installed in my rootfs, which is not desired
for CVEs, image size, etc.

I have 'PACKAGECONFIG:remove = "perl"' in my local.conf and I've verified that postgresql itself is actually configuring with the flag --without-perl,
but postgresql.do_prepare_recipe_sysroot adds a dependency on perl.

I've created an attached patch (0001-cpan-base-Only-RDEPEND-on-perl-if-using-perl.patch) that limits the perl
runtime dependency based on the PACKAGECONFIG of the package that inherits cpan-base, but I'm not certain such
action is wise.

Is there a better way to have postgresql in my image and not have perl?

Thanks!
Comment 1 Randy MacLeod 2024-07-25 14:44:54 UTC 
The patch is a good start, Ross is going to comment on how to proceed.

This isn't a oe-core recipe so since the changes are likely only to the recipe, we're going to reject the bug for now.
Comment 2 Ross Burton 2024-07-25 14:48:17 UTC 
You can't check a PACKAGECONFIG in a base class unless its a well known and defined PACKAGECONFIG, which 'perl' is not.

The cpan class is designed for recipes that fetch perl modules from cpan, so that class depending on perl makes sense.

I can't see why the postgresql recipe actually pulls that class in at all.  Would you be able to test a build of postgresql with perl enabled, but change the cpan-base inherit to perl-version?
Comment 3 Tim Orling 2024-07-25 14:54:10 UTC 
I'd suggest removing cpan-base from:
https://git.openembedded.org/meta-openembedded/tree/meta-oe/recipes-dbs/postgresql/postgresql.inc#n40

And add a line where the inherit conditionally happens if the perl PACKAGECONFIG is set.

And please send patches to the mailing list:
https://git.openembedded.org/meta-openembedded/tree/meta-oe/README.md
Comment 4 Barry G 2024-07-25 15:01:44 UTC 
(In reply to Ross Burton from comment #2)
> You can't check a PACKAGECONFIG in a base class unless its a well known and
> defined PACKAGECONFIG, which 'perl' is not.

Thanks for the explanation. I figured patch was sketchy.

> The cpan class is designed for recipes that fetch perl modules from cpan, so
> that class depending on perl makes sense.
> 
> I can't see why the postgresql recipe actually pulls that class in at all. 
> Would you be able to test a build of postgresql with perl enabled, but
> change the cpan-base inherit to perl-version?

Swapping cpan-base to perl-version in the inherit leads to:
Traceback (most recent call last):
  File "Var <PERLCONFIGTARGET>", line 1, in <module>
bb.data_smart.ExpansionError: Failure expanding variable PERLCONFIGTARGET, expression was ${@is_target(d)} which triggered exception NameError: name 'is_target' is not defined
The variable dependency chain for the failure is: PERLCONFIGTARGET

Since they call that is_target function on https://github.com/openembedded/meta-openembedded/blob/scarthgap/meta-oe/recipes-dbs/postgresql/postgresql.inc#L126
Comment 5 Barry G 2024-08-05 14:37:20 UTC 
Just for administrative housekeeping; I submitted a patch to meta-openembedded:
https://github.com/openembedded/meta-openembedded/commit/f311f1f01c19924d8cced61fa915f1387f92455b

Thanks!