RFE: get rid of Perl based tools to reduce dependencies

[sharkcz]

While working on the "Modular Fedora" project, where one of the goals to reduce the size of the installed content, the team realized that there are some tools written in Perl dragging it into the system. I think the most prominent one is the zipl_helper.device-mapper helper script in zipl, but there are few more.

[michael-holzheu]

@sharkcz : Could you please provide some more information / links on "Modular Fedora"?
Aren't there thousands of perl programs for Linux? Do you want to eliminate them all?

[michael-holzheu]

@oberpar : FYI - since zipl helper explicitly has been mentioned here.

[sharkcz]

The idea is to start with a rather minimal system and then add content on top of that, you can find more at https://github.com/fedora-modularity/hp and https://fedoraproject.org/wiki/Modularity (and more). As the bootloader is always part of the minimal system (on all arches) to make system usable at all it's now dragging Perl into the package set (on s390x). Similar problem on ppc is tracked in https://bugzilla.redhat.com/show_bug.cgi?id=1463749 There is no problem with Perl in "upper" layers.

[michael-holzheu]

Ok, so your goal is that the base-runtime (?) minimal system does not contain Perl.

Currently for RHEL7.4 we have the following Perl programs in s390utils-base:

$ grep -r "usr/bin/perl" *
lib/s390-tools/zipl_helper.device-mapper:#!/usr/bin/perl -w
lib/s390-tools/cpumf_helper:#!/usr/bin/perl -W
sbin/zfcpdbf:#!/usr/bin/perl
usr/sbin/ip_watcher.pl:#!/usr/bin/perl -w
usr/sbin/chmem:#!/usr/bin/perl
usr/sbin/lsmem:#!/usr/bin/perl
usr/sbin/chcpumf:#!/usr/bin/perl -W
usr/sbin/lsluns:#!/usr/bin/perl
usr/bin/lscpumf:#!/usr/bin/perl -W

What should be part of the base-runtime? Only glibc?

[sharkcz]

Ok, so your goal is that the base-runtime (?) minimal system does not contain Perl.

right, respectively removing Perl, which is not used otherwise, is a way to reach the goal

What should be part of the base-runtime? Only glibc?

AFAIK that's still not fully defined, but I would expect that none toolkit libs will be available directly, some might come via dependencies, but that can't be relied on.

One can imagine the "base runtime" as init (systemd) + ssh + shell + package management.

[michael-holzheu]

One can imagine the "base runtime" as init (systemd) + ssh + shell + package management.

Ok thanks, so what exactly is your suggestion? Rewrite the zipl helper in C and remove the remaining Perl tools from s390utils-base?

[sharkcz]

yes, I would suggest to rewrite the zipl helper in C, for the other Perl based tools we can move them to an optional subpackage (I don't think they are mandatory for a boot) and in longer term rewrite them as well. AFAIK it already happened to some other tools (lsmem/chmem in C got even added to util-linux).

[michael-holzheu]

I would suggest to rewrite the zipl helper in C

In case we agree to that plan, do you expect IBM to do that or will "someone else" do the job?

[sharkcz]

Good question :-) It could be IBM or RH (or anyone else), depending on time frame, resources, etc. Definitely not the case that we expect only IBM must do it.

BTW the libraries from the util-linux package might be useful for the rewrite.

[michael-holzheu]

BTW the libraries from the util-linux package might be useful for the rewrite.

Which are GPL v2, no?

[sharkcz]

the libs are under LGPLv2+

[michael-holzheu]

@sharkcz : We discussed your issue internally an came to the following conclusion:

• There are no objections against rewriting the zipl helper in C

If you want IBM to do this, you probably should request this via our official distribution channels.
But since we are "open" now, we would be also glad to accept your first contribution ;-)

Regarding the question about util-linux libraries:

Because of the license issue, I would first try to use our s390-tools internal library, e.g. "libutil/util_path.c" or "util_scandir.c". In case you require more functionality, we could also expand the library.

[sharkcz]

@r4f4 is looking into it