Bizarre Dependencies on Update

[dd_wizard]

I'm wondering if this is a bug, an over zealous requires builder, or necessary?

$ sudo dnf update
Dependencies resolved.
================================================================================================
 Package                        Arch           Version                    Repository       Size
================================================================================================
Installing:
 apache-commons-cli             noarch         1.2-13.fc21                fedora           51 k
 apache-commons-logging         noarch         1.1.3-14.fc21              fedora           83 k
 autoconf                       noarch         2.69-16.fc21               fedora          708 k
 automake                       noarch         1.14.1-5.fc21              fedora          693 k
 cpp                            x86_64         4.9.2-1.fc21               fedora          7.0 M
 eclipse-equinox-osgi           x86_64         1:4.4.1-7.fc21             updates         1.4 M
 gcc                            x86_64         4.9.2-1.fc21               fedora           18 M
 geronimo-jms                   noarch         1.1.1-19.fc21              fedora           31 k
 glibc-devel                    x86_64         2.20-7.fc21                updates         902 k
 glibc-headers                  x86_64         2.20-7.fc21                updates         489 k
 hawtjni                        noarch         1.10-2.fc21                fedora          147 k
 jansi                          noarch         1.11-6.fc21                fedora           44 k
 jansi-native                   x86_64         1.5-8.fc21                 fedora           49 k
 javamail                       noarch         1.5.1-3.fc21               fedora          648 k
 jline                          noarch         2.10-14.fc21               fedora          112 k
 kernel-headers                 x86_64         3.17.8-300.fc21            updates         947 k
 libmpc                         x86_64         1.0.2-3.fc21               fedora           55 k
 libtool                        x86_64         2.4.2-31.fc21              fedora          593 k
 log4j                          noarch         2.0-1.fc21                 fedora          824 k
 log4j12                        noarch         1.2.17-7.fc21              fedora          440 k
 mpfr                           x86_64         3.1.2-8.fc21               updates         209 k
 objectweb-asm                  noarch         5.0.2-2.fc21               fedora          578 k
 perl-Data-Dumper               x86_64         2.154-1.fc21               fedora           54 k
 perl-Test-Harness              noarch         3.34-1.fc21                fedora          308 k
 perl-Thread-Queue              noarch         3.05-2.fc21                fedora           18 k
 rhino                          noarch         1.7R4-10.fc21              fedora          1.0 M
 slf4j                          noarch         1.7.7-2.fc21               fedora           53 k
 xbean                          noarch         3.17-2.fc21                fedora          389 k
Upgrading:
 icedtea-web                    x86_64         1.5.2-0.fc21               updates         1.3 M

Transaction Summary
================================================================================================
Install  28 Packages
Upgrade   1 Package

Total download size: 37 M
Is this ok [y/N]: n

Notice the 28 packages, seemingly unrelated, that get installed when upgrading icedtea-web. After doing some digging, the new version of icedtea-web added a requirement for rhino. Installing rhino will pull in all the packages listed in the previous code block. Here's the info on rhino:

$ sudo dnf info rhino
Available Packages
Name        : rhino
Arch        : noarch
Epoch       : 0
Version     : 1.7R4
Release     : 10.fc21
Size        : 1.0 M
Repo        : fedora
Summary     : JavaScript for Java
URL         : http://www.mozilla.org/rhino/
License     : MPLv2.0
Description : Rhino is an open-source implementation of JavaScript written entirely
            : in Java. It is typically embedded into Java applications to provide
            : scripting to end users.

Does it seem reasonable for a JavaScript implementation to require all of those 27 extra packages it wants to install? If not, I'd be happy to open a bug against it.

dd_wizard

[sea]

By the look of what it pulls in, i would assume the packager has mixed up: Requires with BuildRequires within the specfile quite a few times

Otherwise i cant explain the kernel-headers, cpp, autoconf, automake etc...

[ozjd]

Try it with yum update and see if it has the same requirements.

[antikythera]

Why would dnf come up with different package info? Is it a bug in dnf or an error in the package dependency information read by dnf.

Something is definitely amiss.

[michael@nx9105 ~]$ sudo yum install icedtea-web
[sudo] password for michael: 
Loaded plugins: fastestmirror, langpacks, ps
Loading mirror speeds from cached hostfile
 * fedora: mirror.vorboss.net
 * rpmfusion-free: www.mirrorservice.org
 * rpmfusion-free-updates: www.mirrorservice.org
 * rpmfusion-nonfree: www.mirrorservice.org
 * rpmfusion-nonfree-updates: www.mirrorservice.org
 * updates: mirror.vorboss.net
Resolving Dependencies
--> Running transaction check
---> Package icedtea-web.i686 0:1.5.2-0.fc21 will be installed
--> Processing Dependency: tagsoup for package: icedtea-web-1.5.2-0.fc21.i686
--> Processing Dependency: rhino for package: icedtea-web-1.5.2-0.fc21.i686
--> Running transaction check
---> Package rhino.noarch 0:1.7R4-10.fc21 will be installed
--> Processing Dependency: jline for package: rhino-1.7R4-10.fc21.noarch
---> Package tagsoup.noarch 0:1.2.1-8.fc21 will be installed
--> Running transaction check
---> Package jline.noarch 0:2.10-14.fc21 will be installed
--> Processing Dependency: mvn(org.fusesource.jansi:jansi) for package: jline-2.10-14.fc21.noarch
--> Running transaction check
---> Package jansi.noarch 0:1.11-6.fc21 will be installed
--> Processing Dependency: mvn(org.fusesource.jansi:jansi-native) for package: jansi-1.11-6.fc21.noarch
--> Processing Dependency: mvn(org.fusesource.hawtjni:hawtjni-runtime) for package: jansi-1.11-6.fc21.noarch
--> Running transaction check
---> Package hawtjni-runtime.noarch 0:1.10-3.fc21 will be installed
---> Package jansi-native.i686 0:1.5-8.fc21 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package                Arch          Version              Repository      Size
================================================================================
Installing:
 icedtea-web            i686          1.5.2-0.fc21         updates        1.3 M
Installing for dependencies:
 hawtjni-runtime        noarch        1.10-3.fc21          updates        127 k
 jansi                  noarch        1.11-6.fc21          fedora          44 k
 jansi-native           i686          1.5-8.fc21           fedora          47 k
 jline                  noarch        2.10-14.fc21         fedora         112 k
 rhino                  noarch        1.7R4-10.fc21        fedora         1.0 M
 tagsoup                noarch        1.2.1-8.fc21         fedora         113 k

Transaction Summary
================================================================================
Install  1 Package (+6 Dependent packages)

Total download size: 2.7 M
Installed size: 3.4 M
Is this ok [y/d/N]:

[ozjd]

I think it is a bug in dnf. It isn't ready for day to day use yet. Dnf's dependency resolution has some strange behaviour, see this bug - e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1154202

[dd_wizard]

I agree, ozjd. I added a comment comparing the update results for yum and dnf to the bug you linked.

dd_wizard

[ozjd]

I wouldn't expect a fix as dnf developers seem to think that yum never worked properly and dnf does.

[vallimar]

My advice is to ditch DNF and just use YUM. I gave dnf a run for several months but recently switched back to exclusively using YUM because I was tired of the poor results, continued lack of feature parity and it wasn't even any faster anymore. I also hated how it either gave you no info or spammed you with far too much irrelevant info, no middle ground.

[AdamW]

so the issue here is there are various cases where a package manager basically has to guess something.

In this case, what it has to guess is this: "what should I install to provide 'mvn(org.fusesource.hawtjni:hawtjni-runtime)'?"

The reason is that the package jansi-native has a simple unversioned requirement for precisely that - "mvn(org.fusesource.hawtjni:hawtjni-runtime)". You can see it at http://koji.fedoraproject.org/koji/r...?rpmID=5416200 . And you can also see that there are two packages which provide it:

[root@localhost test]# repoquery --whatprovides "mvn(org.fusesource.hawtjni:hawtjni-runtime)"
hawtjni-runtime-0:1.10-3.fc21.noarch
hawtjni-0:1.10-2.fc21.noarch
[root@localhost test]#

so, when a package simply requires that dependency - no other information - the package manager just has to guess. yum and dnf have different logic for making the guess. yum winds up picking hawtjni-runtime (from the 'updates' repo); dnf winds up picking hawtjni (from the 'fedora' repo). This seems to be reproducible, I can see it in a clean test VM. hawtjni has much heavier dependencies than hawtjni-runtime (I'm guessing the -runtime stuff was split into a subpackage in -3 precisely to reduce this dependency problem).

It's hard to draw the line on when a particular guess is a 'bug', but this is probably such a guess, it's hard to make the case that there's any reason to prefer an older package with more dependencies over a newer one with fewer dependencies. It would be appropriate to file this as a bug against dnf.

Edit: bug filed - https://bugzilla.redhat.com/show_bug.cgi?id=1183835