Texlive packaging

Petr Pisar ppisar at redhat.com
Tue Mar 31 13:19:32 UTC 2015

On 2015-03-30, Jason L Tibbitts III <tibbs at math.uh.edu> wrote:
>>>>>> "GH" == Gerd Hoffmann <kraxel at 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

More information about the devel mailing list