On 2015-03-30, Jason L Tibbitts III <tibbs(a)math.uh.edu> wrote:
>>>>> "GH" == Gerd Hoffmann
<kraxel(a)redhat.com> writes:
GH> Makes sense to me, not only for texlive, stuff like perl pkgs from
GH> cpan have pretty standard way to be built too.
It's not just how the packages are built. There are also bundling and
license issues which require manual inspection. The only reason for
allowing texlive would be because it's already undergone a full license
audit. Unless someone has done that for CPAN, I certainly wouldn't vote
for a blanket exception if this came before FPC (which it probably
wouldn't anyway, because this is more of a FESCo issue).
Nobody reviewed CPAN. Each CPAN distribution is reviewed manually when
it's packaged into Fedora.
Actually it's quite common that the license declared by CPAN metadata is
wrong or labeled as `unknown'.
The same applies to bundling as Perl upstream tends to attach C sources
because there is no way for CPAN metadata to express dependencies on
non-Perl code.
Regarding dependencies, CPAN metadata usually declare set of
dependenices which allows to build the package (with vanilla perl) but
it's still far from ideal. Typical upstream mistakes are missing
dependencies on core modules, requiring needless versions (usually those
that the upstream had installed on its machine at the moment of
releasing), and requiring unused modules just only because they are
distributed in the same CPAN distribution as another module which is
actually needed.
-- Petr