Bug 1246712

Unless the same version-release of gnutls i686 and x86_64 packages conflict this is not a bug in gnutls package.

(In reply to Tomas Mraz from comment #1)
> Unless the same version-release of gnutls i686 and x86_64 packages conflict
> this is not a bug in gnutls package.

Well, right now the fedora update repository is showing an update only for the i686 version of the package. It seems that the x86_64 package was previously updated:

[root@lagarcia ~]# rpm -q gnutls
gnutls-3.3.15-1.fc22.x86_64
gnutls-3.3.15-1.fc22.i686
gnutls-3.3.16-1.fc22.x86_64


I only update my system through "dnf upgrade". So, was it expected that I would end up with two x86_64 packages for gnutls? I mean, it seems that something went wrong at some point that the situation with gnutls packages went bogus.

I could agree that this is only an issue if the conflict is between the same version-release of gnutls i686 and x86_64 packages, but I don't remember myself installing different versions of gnutls on my system. I would expect "dnf upgrade" to just work.

I removed gnutls-3.3.15-1.fc22.x86_64 from my system and upgrade is working fine again.

I still thing something went wrong in between previous gnutls updates and I would hope we at least understand what went wrong so that this doesn't affect users in the future. But my issues is solved.

I have experienced same issue along with some other packages. Are there really both i686 and x86_64 needed? http://pastebin.com/2bf3Gnpj

I did the same as Leonardo Garcia upgraded using fedup.

$ rpm -q gnutls
gnutls-3.3.15-1.fc22.x86_64
gnutls-3.3.15-1.fc22.i686
gnutls-3.3.16-1.fc22.x86_64

$ rpm -q wine-core
wine-core-1.7.46-1.fc22.x86_64
wine-core-1.7.46-1.fc22.i686
wine-core-1.7.47-1.fc22.x86_64

$ rpm -q libidn
libidn-1.29-3.fc22.x86_64
libidn-1.29-3.fc22.i686
libidn-1.31-1.fc22.x86_64

I reassign to dnf since I cannot help with that issue.

Right, I believe that the main problem are the duplicates. I think that if you get rid of them, everything should be fine.

I'm not sure what you mean by the duplicates. Is there some packaging guideline for that case?

I mean, that both Leonardo and semiRocket have two versions of gnutls.x86_64 installed. If the get rid of one of these versions, it should be OK.

yes, removing older packages of same architecture then reinstalling newer ones fixed dnf error. Don't know what caused to have multiple versions of packages installed, though.

Actually maybe Ctrl^C at the right/wrong time caused dnf to bail out without cleaning. I remember doing that before error because I wanted to change command line.

It would be good to know whether this Ctrl^C behaviour of dnf is a regression from yum as I do not remember getting such bugzillas before the yum->dnf switch. Perhaps yum handled the Ctrl^C better?

Or perhaps yum could somehow resolve the conflicts in such situation? But I do not believe that is the case.

I am not really sure but I think that Fedup sometimes accidentally installs a duplicate and causes these errors later.

Please note that I did many updates with dnf in between upgrading with fedup with no previous complains. ID 13 was a failed update when I pressed Ctrl^C.

# dnf history
Last metadata expiration check performed 0:01:56 ago on Mon Aug 10 14:25:22 2015.
ID     | Command line             | Date a | Action | Altere
-------------------------------------------------------------------------------
    27 | update                   | 2015-08-10 11:59 | E, I, U        |   75 EE
    26 | reinstall java           | 2015-08-01 13:03 | Reinstall      |    1   
    25 | reinstall systemd system | 2015-07-31 12:34 | Reinstall      |    2   
    24 | --disableplugin=protecte | 2015-07-31 12:33 | Erase          |    2   
    23 | reinstall wine-systemd   | 2015-07-31 12:05 | Reinstall      |    1   
    22 | remove wine-systemd-0:1. | 2015-07-31 12:04 | Erase          |    1   
    21 | install wine             | 2015-07-31 11:58 | Install        |   10   
    20 | reinstall PyYAML.x86_64  | 2015-07-31 11:48 | Reinstall      |   97 EE
    19 | remove PyYAML-0:3.11-7.f | 2015-07-31 11:29 | Erase          |  106 EE
    18 | update                   | 2015-07-31 00:00 | E, I, U        |   98 EE
    17 | remove wine-core-1.7.46- | 2015-07-30 23:54 | Erase          |    1   
    16 | remove wine-opencl-1.7.4 | 2015-07-30 23:45 | Erase          |    2   
    15 | remove libidn-1.29-3.fc2 | 2015-07-30 23:45 | Erase          |    1   
    14 | remove gnutls-3.3.15-1.f | 2015-07-30 23:44 | Erase          |    7   
    13 | update                   | 2015-07-30 15:29 | E, I, U        |  179 **
    12 | install xchat            | 2015-07-30 14:58 | Install        |    3   
    11 | install mplayer          | 2015-07-29 22:10 | Install        |    9   
    10 | update                   | 2015-07-20 11:38 | E, I, U        |   84 EE
     9 | update                   | 2015-07-20 11:32 | E, I, U        |   90 **
     8 | update                   | 2015-07-15 10:21 | Update         |   29   
     7 | update                   | 2015-07-11 16:41 | E, I, U        |   95   
     6 | install pangox-compat.i6 | 2015-07-08 16:01 | Install        |    1   
     5 | update                   | 2015-07-08 14:57 | E, I, U        |  152 EE
     4 | update                   | 2015-06-27 23:47 | O, U           |  157 EE
     3 | update                   | 2015-06-22 01:57 | I, U           |  106 EE
     2 | update kernel            | 2015-06-22 01:50 | E, I           |    7   
     1 | remove kmod-VirtualBox-4 | 2015-06-22 01:47 | Erase          |    5   

# dnf history info 13 | egrep 'libidn|gnutls|wine-core' 
 ** Upgraded gnutls-3.3.15-1.fc22.i686                                 (unknown)
 ** Upgraded gnutls-3.3.15-1.fc22.x86_64                               (unknown)
 ** Upgraded gnutls-dane-3.3.15-1.fc22.x86_64                          (unknown)
 ** Upgraded gnutls-utils-3.3.15-1.fc22.x86_64                         (unknown)
 ** Upgraded libidn-1.29-3.fc22.i686                                   (unknown)
 ** Upgraded libidn-1.29-3.fc22.x86_64                                 (unknown)
 ** Upgraded wine-core-1.7.46-1.fc22.i686                              @updates
 ** Upgraded wine-core-1.7.46-1.fc22.x86_64                            @updates

<a href="http://pastebin.com/2qcAcTXC"># dnf history info 13</a>

Hello,

dnf team highly suspect the fedup tool to be the source of this issue, since it probably installed mentioned package duplicates.

Uh, I misread some of your comments. Leonardo, have you also cancelled (Ctrl^C) a DNF transaction in the past? If not, I think we have correctly reassigned this to Fedup. Anyway, we need to think about what is the expected behaviour of DNF if Ctrl^C is sent during the installation (but that should be another bug if it behaves wrong).

TBH, I don't remember if I hit Ctrl^C during a DNF update.

Anyway, I think we have a good workaround and, AFAIU, fedup is not anymore the recommended update path (I just updated to Fedora 23 using DNF system-update). So I am closing this bug.