There is no change between old 0.064-1.fc25 and new 0.068-1.fc25 in set of dependencies.

The fat dependencies are optional. The libX11 is dragged in by gd (I don't know why gd library requrires X11) and gd is required by perl-GD-Barcode that's required by perl-Business-ISBN (that's upstream decision to hard-require barcode visualization).

(In reply to Petr Pisar from comment #1)
> There is no change between old 0.064-1.fc25 and new 0.068-1.fc25 in set of
> dependencies.

There's something that's changed that is now pulling it in then.

> The fat dependencies are optional. The libX11 is dragged in by gd (I don't
> know why gd library requrires X11) and gd is required by perl-GD-Barcode
> that's required by perl-Business-ISBN (that's upstream decision to
> hard-require barcode visualization).

Most of that stuff I'm not sure why we need for a "tiny" HTTP server? How can we fix this?

(In reply to Peter Robinson from comment #2)
> > The fat dependencies are optional. The libX11 is dragged in by gd (I don't
> > know why gd library requrires X11) and gd is required by perl-GD-Barcode
> > that's required by perl-Business-ISBN (that's upstream decision to
> > hard-require barcode visualization).
> 
> Most of that stuff I'm not sure why we need for a "tiny" HTTP server?

What? HTTP server? perl-HTTP-Tiny is an HTTP client. And it actually isn't tiny anymore since it supports HTTPS and chunked encoding.

> How can we fix this? 

Set install_weak_deps=false in /etc/dnf/dnf.conf.

Many people say HTTPS should be supported by HTTP client, therefore IO::Socket:SSL is on Recommends and not on Suggests level.

These are perl-HTTP-Tiny-0.068-1.fc26 dependencies:

$ rpm -q --requires -p noarch/perl-HTTP-Tiny-0.068-1.fc26.noarch.rpm | sort -f | grep perl
perl(:MODULE_COMPAT_5.24.0)
perl(bytes)
perl(Carp)
perl(Errno)
perl(Fcntl)
perl(IO::Socket)
perl(MIME::Base64)
perl(Socket)
perl(strict)
perl(Time::Local)
perl(warnings)

$ rpm -q --recommends -p noarch/perl-HTTP-Tiny-0.068-1.fc26.noarch.rpm | sort -f | grep perl
perl(IO::Socket::IP) >= 0.32
perl(IO::Socket::SSL) >= 1.56
perl(Mozilla::CA)

There is nothing we can do in perl-HTTP-Tiny.

The gd packages is pulled in by IO::Socket::SSL:

# LANG=en_US.UTF-8 dnf --allowerasing install 'perl(IO::Socket::SSL) >= 1.56'
Last metadata expiration check: 0:20:33 ago on Fri Sep 30 08:09:00 2016.
Dependencies resolved.
================================================================================
 Package                    Arch      Version                  Repository  Size
================================================================================
Installing:
 gd                         x86_64    2.2.3-2.fc25             rawhide    135 k
 libX11                     x86_64    1.6.3-3.fc24             rawhide    607 k
 libX11-common              noarch    1.6.3-3.fc24             rawhide    163 k
 libXau                     x86_64    1.0.8-6.fc24             rawhide     32 k
 libXpm                     x86_64    3.5.11-5.fc24            rawhide     54 k
 libwebp                    x86_64    0.5.1-1.fc26             rawhide    244 k
 libxcb                     x86_64    1.12-1.fc25              rawhide    208 k
 perl-Business-ISBN         noarch    3.003-1.fc26             rawhide     34 k
 perl-Business-ISBN-Data    noarch    20140910.003-3.fc25      rawhide     32 k
 perl-GD                    x86_64    2.56-9.fc25              rawhide    169 k
 perl-GD-Barcode            noarch    1.15-23.fc25             rawhide    682 k
 perl-IO-Socket-SSL         noarch    2.038-1.fc26             rawhide    260 k
 perl-Mojolicious           noarch    7.08-1.fc26              rawhide    831 k
 perl-Net-SSLeay            x86_64    1.78-1.fc26              rawhide    329 k
 perl-URI                   noarch    1.71-4.fc25              rawhide    116 k

Reassigning to perl-IO-Socket-SSL.

perl-IO-Socket-SSL has a dependency on perl(URI) for public suffix list support. Whilst URI is the preferred back-end for this, it could also use Net::IDN::Encode or Net::LibIDN + Encode, which might be lighter weight options.

perl-URI requires Business::ISBN for ISBN (RFC 3187) support. Again, it's an optional dependency. That's what's pulling in the graphics deps, as mentioned by Petr.

We could make any or all of these weak deps but it wouldn't help the default case where weak deps are enabled.

I suspect the best option would be to downgrade the perl(URI) dependency in perl-IO-Socket-SSL to Suggests: and add a Recommends: perl(Net::IDN::Encode), which wouldn't pull in the graphical deps and Mojolicious.

What about sub-packaging URI::_idna and URI::_punycode? IO::Socket::SSL uses URI::_idna that needs only URI::_punycode and URI::_punycode does not need anything else.

Hmm, that would be nicer. I'll take a look at it.

However, in my opinion, the biggest problem is Business::ISBN requiring GD or URI requiring Business::ISBN. URI module is a quite often dependency and thus cutting the GD from URI would save any URI user and thus provide big relieve to Fedora. I only worry that it will not be easy (or will be impossible). I looked at this problem in the past and I could not found any solution.

Perhaps sub-package perl(URI::urn::isbn) from perl-URI?

(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?

(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)

(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.

> 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.

Any way we can make perl-Business-ISBN / barcode optional for URI. I kind of get why you'd want ISBN as an option in Barcode, even if it is quite a corner case for barcodes, but barcodes for URIs again is quite a corner case (IMO at least) for the average use case for URIs in Fedora. I presume the usecase is for reading of URLs embedded in 2D barcodes?

How about just making perl(Business::ISBN) a Suggests: instead of a Requires: from perl-URI? I think that's how URI's upstream considers it, certainly not as a hard dependency.

That's also an option. And the more I think about all the involved packages, the more it looks like the best solution.

OK, I've done that.

perl-URI-1.71-5.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-5c74e5732c

perl-URI-1.71-5.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.