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

[hoeppnerj]

@sharkcz are there still dependencies to be resolved to address the original issues from your side?
If not, I would consider the whole issue here as being resolved. As far as I can tell, there are still a few
tools left written in perl, but as nothing came in the past, I feel like those tools are no blockers to
the original problem.
What's your stand on the current situation?

[sharkcz]

The urgent needs were resolved by the introduction of the s390utils-core subpackage (see https://src.fedoraproject.org/rpms/s390utils/blob/master/f/s390utils.spec#_173), so flavours like CoreOS can be installed/used without Perl. But the original problem is still there, the regular installer image contains Perl on s390x, increasing its size and dependency chains, while other arches like x86 or aarch64 don't require Perl in the installer image. The general policy is to reduce the number of language environments, so it still makes sense to try to replace Perl with some other language in the remaining tools in the longer term, at least for our s390utils-base (ip_watcher.pl, lsluns, zfcpdbf). The ziomon related tools would be lower priority.

[hoeppnerj]

Alright, thanks for the information. I'll try to address these internally. As far as I understand, this is about the installation
environment. So, there are certainly tools (like lsluns) that could potentially be moved to other subpackages (Like @Benjamin-Block
suggested here already: #22 (comment))

Is this the complete list of the remaining tools that need to be addressed: ip_watcher.pl, lsluns, zfcpdbf ?

[sharkcz]

I believe many people would like to see Perl deprecated globally :-) and I'm thinking about proposing the rewrites as a project for OpenMainframe Project's Internship programme, if it should help to speed up the process and we will agree the perl removal is a good step.

The complete list is bellow, but the 3 tools are the ones present in base. Some might be easy to convert to eg. a shell script.

[dan@talos s390-tools]$ find . -type f | xargs file | grep Perl
./ip_watcher/ip_watcher.pl:                                             Perl script text executable
./ziomon/ziorep_config:                                                 Perl script text executable
./ziomon/ziomon_fcpconf:                                                Perl script text executable
./zconf/lsluns:                                                         Perl script text executable
./scripts/zfcpdbf:                                                      Perl script text executable
./iucvterm/bin/ts-shell.in:                                             Perl script text executable

Putting the Perl tools into a separate subpackage isn't a good solution in my opinion, because it will bring a consistency issue for example (a minimal one, but still).