open($f, q{<:encoding(X)}, q{file}) autoloads PerlIO and PerlIO loads
PerlIO::encoding. The same applies to <:via(), <:mmap etc.
If we subpackaged them we would require each code to list the
dependency explicitly. In general, CPAN has some PerlIO plugins where
it needs to be done so. But there is no reliable scanner to automate
it.
Those are part of one CPAN distribution, but AutoSplit is used only
for building and requires much mode dependencies. Thus I split them
right now.
AutoSplit is usually invoked by ExtUtils::Install (if ./blib/auto
directory exists). This commit also adds the missing dependencies to
perl-ExtUtils-Install subpackage.
The dependencies are stored in gendep.macros file. The file be
regenerated from an RPM build log by ./generatedependencies tool.
The intended work flow is to build a new perl with RPM Perl dependency
generator available locally. Then use this ./generatedependencies tool to
convert the discovered dependencies into the gendep.macro file. Then it's
possible to build the new perl even without the RPM Perl dependency
generator available in the build root while the resulting binary
packages will still posses all dependencies.
The reason is standard perl-genererators is written in the Perl thus
perl-generators must run-require perl. Therefore there is
a build cycle. One could rewrite perl-generators.spec so that it did
not need perl for building, but the run-time dependency would still be
there.
One could claim the one run-time dependency can be satisfied by older
perl. And that's true and it has been done so until now. But that
would not solve the problem when bootrapping perl to a new architecture
or as an excercise the perl can be built without any prior perl
available (required by paranoid users). With pregenerated
dependencies, one can implement real bootstrap.
(Ultimate solution would be reimplement RPM Perl generators in C.)
