Bug 961938

In other words, if a package qualifies under both updating and updating for dependencies, it should go in the updating list.  This bug is new to Fedora 19.

Seconded, this new behavior is inconvenient and confusing, and plain wrong in some cases. Using java-1.7.0-openjdk updates as an example, that's what I have 

$ rpm -qa "java-1.7.0*" | sort
java-1.7.0-openjdk-1.7.0.25-2.3.10.4.fc18.x86_64
java-1.7.0-openjdk-devel-1.7.0.25-2.3.10.4.fc18.x86_64
java-1.7.0-openjdk-src-1.7.0.25-2.3.10.4.fc18.x86_64

$ sudo yum -q upgrade "java-1.7.0*"
Updating:
 java-1.7.0-openjdk-devel   x86_64   1:1.7.0.25-2.3.10.4.fc19   updates   9.1 M
 java-1.7.0-openjdk-src     x86_64   1:1.7.0.25-2.3.10.4.fc19   updates    39 M
Updating for dependencies:
 java-1.7.0-openjdk         x86_64   1:1.7.0.25-2.3.10.4.fc19   updates    25 M

-openjdk should not be in the "for dependencies" section in the above.

$ sudo yum -q upgrade java-1.7.0-openjdk java-1.7.0-openjdk-devel java-1.7.0-openjdk-src
Updating:
 java-1.7.0-openjdk-devel   x86_64   1:1.7.0.25-2.3.10.4.fc19   updates   9.1 M
 java-1.7.0-openjdk-src     x86_64   1:1.7.0.25-2.3.10.4.fc19   updates    39 M
Updating for dependencies:
 java-1.7.0-openjdk         x86_64   1:1.7.0.25-2.3.10.4.fc19   updates    25 M

Again, -openjdk should not be in the "for dependencies" section in the above. But it gets even worse than that:

$ sudo yum -q upgrade java-1.7.0-openjdk
Updating:
 java-1.7.0-openjdk-devel   x86_64   1:1.7.0.25-2.3.10.4.fc19   updates   9.1 M
 java-1.7.0-openjdk-src     x86_64   1:1.7.0.25-2.3.10.4.fc19   updates    39 M
Updating for dependencies:
 java-1.7.0-openjdk         x86_64   1:1.7.0.25-2.3.10.4.fc19   updates    25 M

This one is completely backwards -- in this case openjdk should be in the "Updating" section and -devel and -src in the "for dependencies" section. Doing s/Inconvenient/Incorrect/ in the summary because of that, and marking as regression because this didn't happen in F-18.

At first I thought this might be caused by http://yum.baseurl.org/gitweb?p=yum.git;a=commitdiff;h=ae094fe6d90a2 but that should just move some packages from "depupdated" to "updated" (the other way).  Indeed a bug.. will try to reproduce/fix.

I can't hit this.. What version of Yum are you using?  (This is upstream yum but Java packages from fc17, dependencies should be the same).

# rpm -qa "java-1.7.0*" | sort
java-1.7.0-openjdk-1.7.0.25-2.3.10.3.fc17.i686
java-1.7.0-openjdk-devel-1.7.0.25-2.3.10.3.fc17.i686
java-1.7.0-openjdk-src-1.7.0.25-2.3.10.3.fc17.i686
# yum -q upgrade "java-1.7.0*"

================================================================================
 Package                  Arch Version                    Repository       Size
================================================================================
Updating:
 java-1.7.0-openjdk       i686 1:1.7.0.25-2.3.10.5.fc17   updates-testing  26 M
 java-1.7.0-openjdk-devel i686 1:1.7.0.25-2.3.10.5.fc17   updates-testing 9.1 M
 java-1.7.0-openjdk-src   i686 1:1.7.0.25-2.3.10.5.fc17   updates-testing  39 M

Transaction Summary
================================================================================
Upgrade  3 Packages

It's what's currently in F-19, yum-3.4.3-99.fc19.noarch.

Funny, I cannot reproduce after a 'yum downgrade "java-1.7.0*"' either. But I believe I saw the same effect for some other packages this morning.

IMO the prime suspect is commit ae094fe6d90a2 I've linked in comment#3. It might have some non-obvious implications.  When you hit it again, could you abort the transaction, and retry with ae094fe6d90a2 reverted? (just 2 lines)  Thanks!

I am using yum-3.4.3-99.fc19.noarch.  Commit ae094fe6d90a2 looks correct -- without it, even more packages would be in "Updating for dependencies".  The problem appears to be that txmbr.reason is not set to 'user' even when it should be.  For example, when doing 'yum update' without parameters, the reason should be set to 'user' for all installed packages since the user wants to update everything.

Ok, I can somehow reproduce this, and it's getting pretty complex..  The problem is the interaction with yumdb "reason" attribute.

1) "yum install" shows the split correctly (didn't see any prob here).  Also the reason attribute is set to the expected value (user for explicitly installed, dep for depinstalled packages).

2) "yum update" shows pkg as depupdated if (at install time) it was depinstalled.

3) "yum downgrade" of depinstalled package (reason=dep) changes reason to user.  That's why this can't be easily reproduced after downgrades.

While 3) is probably a bug, one may argue that 2) is correct behavior..   Fixing 3) is probably not easy, and I'm not sure it's worth it.. will try to look at it again tomorrow.

Ok, here's another example from right now, I'm not installing these updates yet in case you want me to try something out:

# rpm -q python3 python3-libs
python3-3.3.2-2.fc19.x86_64
python3-libs-3.3.2-2.fc19.x86_64

----------------------------------

# yumdb info python3 python3-libs
Loaded plugins: dellsysid, langpacks, refresh-packagekit
python3-3.3.2-2.fc19.x86_64
     checksum_data = f64affad2f5a89995f6d2902e6c4a0b62d14403deffda53c5719dbaeee76671f
     checksum_type = sha256
     command_line = --releasever=19 --disablerepo=*dell* distro-sync p* emacs*
     from_repo = fedora
     from_repo_revision = 1372417620
     from_repo_timestamp = 1372419845
     installed_by = 1000
     origin_url = http://www.nic.funet.fi/pub/mirrors/fedora.redhat.com/pub/fedora/linux/development/19/x86_64/os/Packages/p/python3-3.3.2-2.fc19.x86_64.rpm
     reason = dep
     releasever = 19

python3-libs-3.3.2-2.fc19.x86_64
     checksum_data = 37e5f1152d64fdbdd8291578878b54cf78e6d879ab9171fe21d74b5a7bbb9b8e
     checksum_type = sha256
     command_line = --releasever=19 --disablerepo=*dell* distro-sync p* emacs*
     from_repo = fedora
     from_repo_revision = 1372417620
     from_repo_timestamp = 1372419845
     installed_by = 1000
     origin_url = http://www.nic.funet.fi/pub/mirrors/fedora.redhat.com/pub/fedora/linux/development/19/x86_64/os/Packages/p/python3-libs-3.3.2-2.fc19.x86_64.rpm
     reason = dep
     releasever = 19

----------------------------------

# yum -q upgrade
Updating:
 python3             x86_64        3.3.2-3.fc19         updates         43 k
Updating for dependencies:
 python3-libs        x86_64        3.3.2-3.fc19         updates        6.2 M

Both python3 and python3-libs are shown as "reason = dep" in yumdb, so why does one of them end up in updating, and the other in "for dependencies"?

----------------------------------

# yum -q install python3 python3-libs
Updating:
 python3             x86_64        3.3.2-3.fc19         updates         43 k
Updating for dependencies:
 python3-libs        x86_64        3.3.2-3.fc19         updates        6.2 M

This contradicts your point 1) -- yum install shows the same issue. Using upgrade instead of install produces exactly the same result.

When I'm upgrading packages, especially when explicitly naming things to upgrade such as in the above, I don't think the reason why the package was previously installed should affect anything.

Reverting ae094fe6d90a2 didn't make a difference.

James, any idea what might have caused this regression?  Thanks!

Created attachment 772843 [details]
WIP - unit test for catching this

Running out of time today - but figured I'd toss what I've got here which will make it easier to fix as there is now a test.

So I think it's likely to be:

    def _add_up_txmbr(self, requiringPo, upkg, ipkg):
        txmbr = self.tsInfo.addUpdate(upkg, ipkg)
        if requiringPo:
            txmbr.setAsDep(requiringPo)
        if ('reason' in ipkg.yumdb_info and ipkg.yumdb_info.reason == 'dep'):
            txmbr.reason = 'dep'
        return txmbr


As the original was a dep, this gets propagated, but I've not verified that.

Created attachment 772845 [details]
Fix to be applied on top of previous patch

make test passes now.

Alas. adding that test just makes the if a noop, as txmbr.reason starts off == 'user'.

In Paul's testcase, bar12 is getting it's setAsDep() call from (depsolve):

            #Add relationship
            for po in provs:
                if txmbr.name == po.name:
                    continue
                for member in self.tsInfo.getMembersWithState(
                    pkgtup=po.pkgtup, output_states=TS_INSTALL_STATES):
                    member.setAsDep(txmbr.po)

...which has been there "forever".

This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.