https://bugzilla.redhat.com/show_bug.cgi?id=1380152 --- Comment #11 from Petr Pisar <ppisar@xxxxxxxxxx> --- (In reply to Paul Howarth from comment #10) > (In reply to Peter Robinson from comment #9) > > (In reply to Petr Pisar from comment #7) > > > However, in my opinion, the biggest problem is Business::ISBN requiring GD > > > > what functionality does GD as a graphics library provide to a ISBN library? > > Per Comment #1: > > perl-GD-Barcode is required by perl-Business-ISBN (that's upstream > decision to hard-require barcode visualization) The issue with perl-Business-ISBN is, both ISBN string parser and string-to-PNG convertor are defined in the same file. It's impossible to split the two features into two RPM packages. But the current code looks like: sub png_barcode { my $self = shift; my $ean = $self->as_isbn13->as_string([]); eval "use GD::Barcode::EAN13"; if( $@ ) { carp "Need GD::Barcode::EAN13 to use png_barcode!"; return; } my $image = GD::Barcode::EAN13->new($ean)->plot->png; return $image; } So it looks like upstream tries loading the GD library only when needed. The question is whether he did for performance or for making the dependency optional. Raising exception instead of returning undef does not evoke the optionality is an intended first class citizen. Or maybe the upstream just does not know a "use" can be replaced by "require; ->import()". But purely technically, it allows us to make the dependency optional on RPM level because it will not crash in all uses cases. But honestly, I still don't feel comfortable with this definition of optionality. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ perl-devel mailing list -- perl-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to perl-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
