are you able to reproduce this again? On my system when I tried I can't reproduce this. 

Also, if you want to debug dependencies issues try adding "--debugsolver" option and in the current working directory you will get result in debugdata directory. You can check files in it and if see something wrong can upload here.

Could you please provide us your versions of rpm + dnf and also try remove libidn directly from rpm?

AHA. I think I found the problem! 

It turns out that the `plexmediaserver` RPM I had installed on this system claimed to provide libidn.so:

  [root@kraid ~]# rpm -q --provides plexmediaserver | grep idn
  libidn.so.11()(64bit)
  libidn.so.11(LIBIDN_1.0)(64bit)

Also, that RPM had been installed using PackageKit, which does *not* mark packages as 'userinstalled', so DNF/hawkey/libsolv considered plexmediaserver
sufficient to provide everything that libidn provided, which made it eligible for autoremoval.

Reinstalling the package using DNF was sufficient to fix the problem:

  diff -u pkcon-install/solver.result dnf-install/solver.result
  --- pkcon-install/solver.result
  +++ dnf-install/solver.result
  @@ -1,3 +1,2 @@
   erase dnf-plugin-system-upgrade-0.4.0-1.fc22.noarch@@System
  -erase libidn-1.32-1.fc22.x86_64@@System
   erase python2-dnf-plugin-system-upgrade-0.4.0-1.fc22.noarch@@System
  diff -u pkcon-install/testcase.t dnf-install/testcase.t
  --- pkcon-install/testcase.t
  +++ dnf-install/testcase.t
  @@ -1322,6 +1322,7 @@
   job userinstalled pkg pkcs11-helper-1.11-5.fc22.x86_64@@System
   job userinstalled pkg pkgconfig-1:0.28-8.fc22.x86_64@@System
  +job userinstalled pkg plexmediaserver-0.9.12.11.1406-8403350.x86_64@@System
   job userinstalled pkg plymouth-0.8.9-9.2013.08.14.fc22.x86_64@@System
   job userinstalled pkg plymouth-devel-0.8.9-9.2013.08.14.fc22.x86_64@@System

So! There's two problems that caused this behavior:

  1) plexmediaserver lies about its provides
  2) PackageKit doesn't mark user-installed packages correctly

The first one is Plex's problem, and the second is PackageKit's. The latter should probably get filed somewhere, but otherwise we won't worry about those here.

The only remaining DNF issue is this: How do I *keep* DNF from trying to remove libidn? --exclude=libidn doesn't work:

  [root@kraid dnf]# dnf erase --exclude=libidn.* dnf-plugin-system-upgrade
  Dependencies resolved.
  ==========================================================================
   Package                            Arch    Version        Repository Size
  ==========================================================================
  Removing:
   dnf-plugin-system-upgrade          noarch  0.4.0-1.fc22   @System   71 k
   libidn                             x86_64  1.32-1.fc22    @System  647 k
   python2-dnf-plugin-system-upgrade  noarch  0.4.0-1.fc22   @System   51 k

I did figure out that "--setopt clean_requirements_on_remove=no" disables the autoremove behavior:

  [root@kraid dnf]# dnf erase python2-dnf-plugin-system-upgrade \
                              --setopt clean_requirements_on_remove=no
  Dependencies resolved.
  ==========================================================================
   Package                            Arch    Version        Repository Size
  ==========================================================================
  Removing:
   dnf-plugin-system-upgrade          noarch  0.4.0-1.fc22   @System   71 k
   python2-dnf-plugin-system-upgrade  noarch  0.4.0-1.fc22   @System   51 k

So. Maybe '--exclude' behavior needs to extend to autoclean, or maybe it might be helpful to have a simpler CLI flag for disabling autoclean?

Beyond that suggestion, there's nothing to really fix in DNF here. I'll leave it to the assignees, but this could probably be closed CANTFIX.

(In reply to Will Woods from comment #3)
> AHA. I think I found the problem! 
> 
> It turns out that the `plexmediaserver` RPM I had installed on this system
> claimed to provide libidn.so:

Great you have found the problem.

> So! There's two problems that caused this behavior:
> 
>   1) plexmediaserver lies about its provides

It doesn't seem to be in Fedora repos so you should report this incident somewhere else.

>   2) PackageKit doesn't mark user-installed packages correctly

Then I will reassign this to PK to mark packages as userinstalled from DNF cli. Can you call from PK at the end of successful transaction `dnf mark install <packages that user requested for an installation...>` [1], please? (It acts the same as changing `reason` for the package to `user` in yumdb)

> The only remaining DNF issue is this: How do I *keep* DNF from trying to
> remove libidn? --exclude=libidn doesn't work:

`dnf mark install libidn` will tag the package as userinstalled. (Command vailable from dnf-1.1.1)

[1] http://dnf.readthedocs.org/en/latest/command_ref.html#mark-command

Just wanted to note that simply *upgrading* packages via PackageKit also causes them to be marked as not userinstalled. Currently on my system, libreoffice and whole bunch of important system packages like selinux-policy are at risk of being autoremoved.

Therefore any potential fix should take into consideration that upgrading a package should maintain its current userinstalled status. Any userinstalled packages being upgraded should remain userinstalled and any automatically installed for dependency reasons should likewise remain marked as auto installed.

Is marking userinstalled the same as just setting the reason file in the dnfdb to be "user"? If so, we should be doing that already...

Somehow we end up with "dep":

[kalev@beagle ~]$ ls /var/lib/dnf/yumdb/g/*gnome-clocks*
ls: cannot access /var/lib/dnf/yumdb/g/*gnome-clocks*: No such file or directory
[kalev@beagle ~]$ pkcon install gnome-clocks
Resolving                     [=========================]         
Testing changes               [=========================]         
Finished                      [=========================]         
Installing                    [=========================]         
Waiting for authentication    [=========================]         
Querying                      [=========================]         
Downloading packages          [=========================]         
Testing changes               [=========================]         
Installing packages           [=========================]         
Finished                      [=========================]         
[kalev@beagle ~]$ ls /var/lib/dnf/yumdb/g/*gnome-clocks*
from_repo  installed_by  reason  releasever
[kalev@beagle ~]$ cat /var/lib/dnf/yumdb/g/*gnome-clocks*/reason
dep[kalev@beagle ~]$

(In reply to Richard Hughes from comment #6)
> Is marking userinstalled the same as just setting the reason file in the
> dnfdb to be "user"? If so, we should be doing that already...

Yes, it's the same but `mark` is the official way to do this.

Yes I just tried installing ghex via Gnome Software and the reason file states "dep" for me as well, instead of "user".


I also have a lot of other system packages in the autoremove list (some of them pretty important) that have "unknown" in the reason file.

(In reply to Jan Silhan from comment #8)
> (In reply to Richard Hughes from comment #6)
> > Is marking userinstalled the same as just setting the reason file in the
> > dnfdb to be "user"? If so, we should be doing that already...
> 
> Yes, it's the same but `mark` is the official way to do this.

Do you mean Software should exec the DNF binary? That doesn't seem right.

This is still an issue in F23.

*** Bug 1284194 has been marked as a duplicate of this bug. ***

(In reply to Mike Goodwin from comment #11)
> This is still an issue in F23.

Confirmed here as well. I am refusing to use Gnome Software until this is resolved.

*** Bug 1286724 has been marked as a duplicate of this bug. ***

There is no need to explicitly mark packages since DNF treats all packages without reason in dnf's yumdb as installed by user. PackageKit unfortunately incorrectly marks all of installed packages with reason 'dep' as I described in #1284194.

(In reply to Michal Luscon from comment #15)
> There is no need to explicitly mark packages since DNF treats all packages
> without reason in dnf's yumdb as installed by user. PackageKit unfortunately
> incorrectly marks all of installed packages with reason 'dep' as I described
> in #1284194.

I think it would still make sense for PackageKit to correctly mark whether a package has been auto installed or user installed, just so that things are consistent regardless of whether a user is using DNF or Gnome Software to install stuff.

(In reply to Benjamin Xiao from comment #16)

> I think it would still make sense for PackageKit to correctly mark whether a
> package has been auto installed or user installed, just so that things are
> consistent regardless of whether a user is using DNF or Gnome Software to
> install stuff.

Sure, but turning off yumdb writing can be considered as a temporary workaround.

(In reply to Michal Luscon from comment #17)
> Sure, but turning off yumdb writing can be considered as a temporary
> workaround.

What about packages that are pulled in as dependencies by PackageKit? Would they also not have a reason if we turn off yumdb writing? That would mean that a lot of dependencies pulled in by PackageKit will not be marked for autoremove if no packages depend on them in the future.

This will cause the opposite problem where a lot of unnecessary packages persist on a user's system.

*** Bug 1287091 has been marked as a duplicate of this bug. ***

*** Bug 1246570 has been marked as a duplicate of this bug. ***

*** Bug 1288203 has been marked as a duplicate of this bug. ***

Is this getting fixed?

*** Bug 1303721 has been marked as a duplicate of this bug. ***

*** Bug 1295559 has been marked as a duplicate of this bug. ***

Can we get this fixed, please? Either use official way how to install packages from DNF API or set correct values to DNF db afterwards. It removes critical components on system of the users.

Yes, please. We're getting more and more reports, especially in the Fedora subreddit, where people are removing important system packages by accident either by doing autoremove or by using clean_requirements_on_remove and then completely breaking their system.

Somebody should probably change the version this affects also. (22 AND 23)

The workaround is basically to advise people NOT to use PackageKit and those tools that use it (apper, system tray updater, etc)

Alternate workaround too:  disable dnf autoremove feature by default, and consider this issue a blocker to re-enabling it

Since gnome-software is going to be used for performing system upgrades in F24 (thus affecting all packages in this way), I'm proposing this as a blocker. It does not play along with dnf well, causing important packages to be removed when dnf is used.

Here's a trivial reproducer:

[kparal@localhost ~]$ sudo dnf autoremove
Last metadata expiration check performed 0:44:42 ago on Mon Feb 15 10:34:45 2016.
Dependencies resolved.
Nothing to do.
Complete!
[kparal@localhost ~]$ pkcon install simple-scan
Resolving                     [=========================]         
Loading cache                 [=========================]         
Finished                      [=========================]         
Testing changes               [=========================]         
Installing                    [=========================]         
Waiting for authentication    [=========================]         
Downloading packages          [=========================]         
Testing changes               [=========================]         
Installing packages           [=========================]         
Finished                      [=========================]         
[kparal@localhost ~]$ sudo dnf autoremove
Last metadata expiration check performed 0:45:02 ago on Mon Feb 15 10:34:45 2016.
Dependencies resolved.
======================================================================================
 Package              Arch            Version                 Repository         Size
======================================================================================
Removing:
 simple-scan          x86_64          3.19.4-2.fc24           @rawhide          1.5 M

Transaction Summary
======================================================================================
Remove  1 Package

Installed size: 1.5 M
Is this ok [y/N]: n


This happens with:
PackageKit-1.1.0-1.fc24.x86_64
libhif-0.2.2-1.fc24.x86_64
gnome-software-3.19.4-2.fc24.x86_64
dnf-1.1.6-2.fc24.noarch
rpm-4.13.0-0.rc1.23.fc24.x86_64
librepo-1.7.17-3.fc24.x86_64
hawkey-0.6.2-4.fc24.x86_64

Discussed at 2016-02-15 blocker review meeting: [1]. 

This bug was accepted as a Beta blocker: we hold this violates combination of "The installed system must be able to download and install updates with the default console package manager." (Alpha) and "The installed system must be able to download and install updates with the default graphical package manager in all release-blocking desktops." (Beta) as it's believed that doing the former after the latter could remove critical packages

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2016-02-15/f24-blocker-review.2016-02-15-17.00.html

*** Bug 1309314 has been marked as a duplicate of this bug. ***

*** Bug 1309513 has been marked as a duplicate of this bug. ***

As a progress update, I was talking with Kalev Lember about this today. His response was "I'll see if I can come up with a fix for this this week".

(In reply to Benjamin Xiao from comment #18)
> (In reply to Michal Luscon from comment #17)
> > Sure, but turning off yumdb writing can be considered as a temporary
> > workaround.
> 
> What about packages that are pulled in as dependencies by PackageKit? Would
> they also not have a reason if we turn off yumdb writing? That would mean
> that a lot of dependencies pulled in by PackageKit will not be marked for
> autoremove if no packages depend on them in the future.
> 
> This will cause the opposite problem where a lot of unnecessary packages
> persist on a user's system.

I would like to stress the importance of what Ben is saying here as I've also verified this behavior in an unintended way (researching what happens when you mess with /var/lib/dnf/yumdb/*/*/reason in various ways) 

The solution in PK must first observe if the package has an existing reason file, and copy that reason through during an upgrade. If and when a new package dependency is pulled in by PK and it doesn't create the proper corresponding entries in /var/lib/dnf/yumdb/*/ then DNF will in fact treat it as a @System userinstalled package. 

This is obviously undesirable because there will then be no truthful way for the user to remove unneeded dependencies, causing the system to balloon over time.

I looked into fixing this up last week and posted the patches to

http://paste.fedoraproject.org/358110/14612403/ (libhif)
http://paste.fedoraproject.org/358111/ (PackageKit)

Richard wanted to have tests covering the area before merging the fixes though, so this may take a bit before the fixes get merged upstream into libhif. The whole installing rpms area is currently lacking tests and we need to come up with an infrastructure for them in libhif before we can actually write tests for yumdb writing.

Kalev, thanks for the update. I understand the need for tests in these system critical areas. However, please note that this is one of the two blockers Fedora 24 Beta is waiting on and Go/NoGo is tomorrow (which is going to be NoGo, as it seems), so this might not be a good time to start creating a test infrastructure from scratch, in case it would take weeks, not days. Is it possible to come up with something that would be done relatively fast (ideally this week, so that we have time to test it)? Thanks.

Richard, what do you think?

I've built this as https://copr.fedorainfracloud.org/coprs/rhughes/f23-gnome320/build/181352/ without the tests. Please test!

libhif-0.2.2-3.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-1f7048425f

One of the major cases to this bug is in installing updates graphically, can someone confirm that this libhif update does not blindly mark all packages that it handles user installed? I would be a shame if all dep updates -> user. 

I don't have the appropriate time or setup at the moment to do it myself, thanks!

FYI it's the phrasing "fixes an issue where installs / updates done through PackageKit incorrectly marked packages as dependencies where they should have been marked as user installed" in the update notes that causing me concern.

(In reply to Mike Goodwin from comment #41)
> One of the major cases to this bug is in installing updates graphically, can
> someone confirm that this libhif update does not blindly mark all packages
> that it handles user installed? I would be a shame if all dep updates ->
> user.

Nope, it doesn't blindly mark everything as "user", just things that are explicitly installed. Dependencies get marked as "dep". Hopefully, I mean. Barring any bugs.

Testing welcome in any case :)

I try to test this extensively and it seems to work well. Only requested packages are marked as userinstalled, their deps are not. You can mix and match pkcon and dnf operations. Updating existing packages keeps the current flags.

(Please note we'll need a similar fix in F23, in order to support graphical system upgrades using gnome-software. Please add the fixed libhif to the copr repo, thanks.)

Thanks Kamil. I think updated libhif could even go to F23 proper -- it basically just has bug fixes compared to the current F23 libhif build.

I can help test on F23 if packages are available.

Thanks for the fix! I've been waiting for this for a while. I was afraid to use Gnome Software for basically all of F23.

(In reply to Benjamin Xiao from comment #45)
> I can help test on F23 if packages are available.

The fix is not yet available for F23, we will mention it here once it is.

(In reply to Kalev Lember from comment #44)
> I think updated libhif could even go to F23 proper -- it
> basically just has bug fixes compared to the current F23 libhif build.

If the changes seem safe enough, please put it into bodhi and set a high karma threshold for it (or better yet disable autopush completely), so that we can properly test it and make sure it doesn't break anything. Thanks.

(In reply to Kamil Páral from comment #47)
> If the changes seem safe enough, please put it into bodhi and set a high
> karma threshold for it (or better yet disable autopush completely), so that
> we can properly test it and make sure it doesn't break anything. Thanks.

Second this.

libhif-0.2.2-3.fc24 has been pushed to the Fedora 24 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-1f7048425f

libhif-0.2.2-3.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-ba5f1759c7

(In reply to Kamil Páral from comment #47)
> (In reply to Kalev Lember from comment #44)
> > I think updated libhif could even go to F23 proper -- it
> > basically just has bug fixes compared to the current F23 libhif build.
> 
> If the changes seem safe enough, please put it into bodhi and set a high
> karma threshold for it (or better yet disable autopush completely), so that
> we can properly test it and make sure it doesn't break anything. Thanks.

Done.

libhif-0.2.2-3.fc23 has been pushed to the Fedora 23 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-ba5f1759c7

This works as I would expect it to.

My test case was htop I first removed it, installed it with apper, downgraded it with dnf, then upgraded it with the system-tray updater (im a KDE user)

Under all circumstances the file had the correct reason in /var/lib/dnf/yumdb/h/*/reason and as a result showed up under `sudo dnf history userinstalled` and was not wanted to be removed by `sudo dnf autoremove`

I will continue to use this to install updates and report back as necessary.

Thanks!

I started to get my system into a state to test this and realised I was only not bitten by the dnf autoremove bug due to luck on autoremove wanting to get rid of 32bit libraries required by steam and then getting a package DB error with the 64bit ones there as well.

After marking the 64 bit ones as user installed (no 64 bit steam to have them appear as dependencies) a large proportion of my system wanted to be removed on a dnf autoremove ...

I'm slowly working my way through to mark as user installed things I know are not dependencies but the regular user is not going to be able to handle that.

It's all well and good fixing the ongoing issue but how can the existing situation be retrofitted with the correct reason to avoid half the system being removed?

At the least should we have on the F24 common bugs page the steps to verify if autoremove is dangerous on the system in question (just an  dnf  --assumeno autoremove is enough to check what will go) along with the dnf mark install mantra) that a user can go through to avoid issues or recover safely prior to/during the F24 update?

*** Bug 1320713 has been marked as a duplicate of this bug. ***

I agree, we should figure out what we can advise to users already affected by this, because this is not going to fix the userinstalled flags retroactively. So even if they update to latest libhif, dnf still might autoremove half of their system at any point in the future.

Kalev, Richard, Jan, any advice here? Can we do something better than running "dnf mark install" for all installed packages (very suboptimal, but still better than not doing it)?

(In reply to Kamil Páral from comment #56)
> Kalev, Richard, Jan, any advice here? Can we do something better than
> running "dnf mark install" for all installed packages (very suboptimal, but
> still better than not doing it)?

I don't have any good ideas, sorry.

Rather than mark *everything* installed as user, can we perhaps walk the tree and mark those without anything dependent on them ... set those to user?

Their dependencies would still be dep then and correctly removed if the user removes them.

It's not perfect but would be better than ignoring the issue or marking everything user, thus negating the point of autoremove, as a middle ground?

libhif-0.2.2-3.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.

(In reply to James Hogarth from comment #58)
> Rather than mark *everything* installed as user, can we perhaps walk the
> tree and mark those without anything dependent on them ... set those to user?

I tried this, with clean F23 installed from Live, then fully updated using PackageKit, and then retrieving all leave packages using `package-cleanup --all --leaves` and marking them as installed. It solved the problem for that very moment. However, some of the packages which were marked as userinstalled originally, were not marked as such afterwards (examples: alsa-utils, avahi, bash). They got updated (therefore stripped of userinstalled flag), but were not leaves (therefore the flag was not added by my script). There is a real chance that the user can uninstall something that has those packages as deps, they become leave packages, and they'll get removed with the next dnf transaction.

The only safe way seems to be marking all installed packages as userinstalled. It's ineffective, but it's the best way to ensure people won't lose important packages unexpectedly.

Kalev, the fc23 update has received a good amount of karma and has been in testing for more than a week. I think it should be safe now to push it into updates. Thanks.

Submitted to stable now, thanks.

libhif-0.2.2-3.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

*** Bug 1338198 has been marked as a duplicate of this bug. ***

and because of such annoying bugs "yum-utils" aka "package-cleanup --leaves" or "package-cleanup --leaves --all" should babble about deprecation until it's functionality is 100% ported to DNF

and NO- i am not talking about some "dnf magickcommand" but "package-cleanup" as it is and works rock solid for many years, long before DNF was planned and currently too

The F24 release notes have suggestions on what to do if you have been affected by this issue to assist in cleaning up the fallout.  Applies to F23 also.

https://fedoraproject.org/wiki/Common_F24_bugs#DNF_might_remove_essential_system_packages_if_you_used_PackageKit_.28GNOME_Software.2C_KDE_Apper.29_in_the_past

@Gerald Cox in the link you provided they suggest to mark "all" the packages as system-required.

I'm wondering if it would be possible to be more precise in marking the packages, perhaps following these steps:

1) setup a VM with a Fedora "vanilla" version

2) obtain the list of packages marked as "user installed" from that Fedora where the bug was not exploited

3) Use that list of packages to mark as "user installed" the packages in a pc with "broken" Fedora. This should reduce significantly the number of packages that are not correctly marked as "user installed"

4) Run trough the list of the remaining packages that DNF would like to remove and manually mark the ones that the user knows he manually installed

5) if some packages remain from the selections operated at steps 3) and 4), then either mark them as user installed or allow them to be removed. Of course in the latter case one must know what he's doing.

Could this work in your opinion?
Thanks

(In reply to Giordano Battilana from comment #67)
> @Gerald Cox in the link you provided they suggest to mark "all" the packages
> as system-required.
> 
...
> 
> Could this work in your opinion?
> Thanks

I asked a question about this on the development list, and the above was the suggested recommendation.  I was thinking that for F24, this would be automagically resolved during the upgrade process, but apparently there is a chance that some of the packages on your system may be removed instead of upgraded.  This is indeed a nasty bug because depending on which package "may" be removed it could cause havoc on your system.  

I believe you can see which packages which are affected by issuing:  
dnf autoremove

BE SURE TO REMOVE N to the prompt so you don't actually remove anything.  I have been doing a "dnf reinstall" package_name on the packages that I want to be sure are retained.  I believe the idea behind the recommendation in the release notes was it was a quick and easy way to ensure you wouldn't be negatively impacted by the fallout from this bug.  Yes, there is a possibility that it will keep a few extra packages on your system that aren't needed, but we're talking about a really small amount of space.  The idea being that the time and effort to figure out what you need and what you don't need may not be worth it - and I tend to agree with that assessment.

What does `Package gpg-pubkey is not installed.` mean?

https://gist.github.com/sudhirkhanger/35ae78b0399d083dee76a19858f61f30

(In reply to Sudhir Khanger from comment #69)
> What does `Package gpg-pubkey is not installed.` mean?

It's harmless. RPM prints imported keys inside the `rpm -qa` output, even though they are not packages. Therefore they can't be marked as userinstalled. No issue.

*** Bug 1327556 has been marked as a duplicate of this bug. ***

*** Bug 1290921 has been marked as a duplicate of this bug. ***

*** Bug 1277115 has been marked as a duplicate of this bug. ***

Hi.

I think I discovered that this bug is still existing "autoremove" try to remove essential packages or packages that should not be removed.

1st please know the following:

- I use Fedora 24 X64 Cinnamon edition (Not GNOME)
- I did not installed GNOME or other DE as additional DE
- I did not installed GNOME software center at all
- I have no packagekit on my system
- I have no libhif on my system

When I saw this bug closed, I asked about this in Fedora help forum at this link:
http://www.forums.fedoraforum.org/showthread.php?t=311685

In forum they ask me to run "sudo dnf autoremove" but not allow it to complete. Just run it, copy list of package that showed to be removed then abort process & ask in forum about these. I did that. The following is the list to be removed:

Last metadata expiration check: 2:38:36 ago on Thu Oct 6 06:52:38 2016.
Dependencies resolved.
================================================== ==============================
Package Arch Version Repository Size
================================================== ==============================
Removing:
GLee x86_64 5.4.0-10.fc24 @fedora 728 k
ImageMagick-c++ x86_64 6.9.3.0-2.fc24 @fedora 625 k
SDL2 x86_64 2.0.4-8.fc24 @updates 1.1 M
atlas x86_64 3.10.2-12.fc24 @anaconda 23 M
aubio x86_64 0.4.2-2.fc24 @fedora 798 k
boost-regex x86_64 1.60.0-7.fc24 @updates 1.1 M
clang-libs x86_64 3.8.0-2.fc24 @updates 28 M
clutter-gst2 x86_64 2.0.18-1.fc24 @anaconda 191 k
compat-lua-libs x86_64 5.1.5-5.fc24 @fedora 485 k
cwiid x86_64 0.6.00-27.20100505gitfadf11e.fc24
@fedora 71 k
fftw-libs-single x86_64 3.3.4-7.fc24 @fedora 2.1 M
frei0r-plugins x86_64 1.5-1.fc24 @fedora 5.1 M
gavl x86_64 1.4.0-8.fc24 @fedora 4.2 M
gmic x86_64 1.7.2-1.fc24 @updates 15 M
hyperv-daemons-license noarch 0-0.14.20150702git.fc24 @anaconda 18 k
hypervfcopyd x86_64 0-0.14.20150702git.fc24 @anaconda 12 k
hypervkvpd x86_64 0-0.14.20150702git.fc24 @anaconda 31 k
hypervvssd x86_64 0-0.14.20150702git.fc24 @anaconda 12 k
kf5-kplotting x86_64 5.26.0-1.fc24 @updates 106 k
ladspa x86_64 1.13-16.fc24 @fedora 116 k
ladspa-swh-plugins x86_64 0.4.15-26.fc24 @fedora 1.5 M
libbs2b x86_64 3.1.0-16.fc24 @fedora 54 k
libclc x86_64 0.2.0-3.20160207gitdc330a3.fc24
@fedora 25 M
libfreenect x86_64 0.5.3-1.fc24 @fedora 370 k
libgdither x86_64 0.6-11.fc24 @fedora 41 k
libguess x86_64 1.2-3.fc24 @fedora 36 k
liblo x86_64 0.28-2.fc24 @fedora 162 k
liblrdf x86_64 0.5.0-10.fc24 @fedora 52 k
libltc x86_64 1.2.0-2.fc24 @fedora 34 k
libmpg123 x86_64 1.22.4-1.fc24 @rpmfusion-free 443 k
liboil x86_64 0.3.16-13.fc24 @fedora 568 k
libopenshot x86_64 0.1.1-2.fc24 @rpmfusion-free 940 k
libopenshot-audio x86_64 0.1.1-1.fc24 @rpmfusion-free 4.8 M
libprojectM-qt x86_64 2.1.0-1.fc24 @fedora 360 k
libresample x86_64 0.1.3-22.fc24 @fedora 53 k
librtmp x86_64 2.4-7.20160224.gitfa8646d.fc24
@rpmfusion-free-updates
152 k
libunicap x86_64 0.9.12-17.fc24 @fedora 401 k
lilv x86_64 0.20.0-5.fc24 @fedora 153 k
lirc-libs x86_64 0.9.4a-1.fc24 @updates 282 k
mencoder x86_64 1.3.0-1.fc24 @rpmfusion-free 2.6 M
mesa-libOpenCL x86_64 12.0.3-1.fc24 @updates 1.8 M
mjpegtools-libs x86_64 2.1.0-5.fc24 @rpmfusion-free 392 k
mkvtoolnix x86_64 9.2.0-1.fc24 @updates 17 M
mlt-python x86_64 6.2.0-2.fc24 @rpmfusion-free-updates
622 k
mplayer x86_64 1.3.0-1.fc24 @rpmfusion-free 3.8 M
mplayer-common x86_64 1.3.0-1.fc24 @rpmfusion-free 1.3 M
oggvideotools x86_64 0.9-2.fc24 @fedora 4.7 M
ogmtools x86_64 1.5-17.fc24 @fedora 410 k
opencl-filesystem noarch 1.0-4.fc24 @fedora 0
opencore-amr x86_64 0.1.3-4.fc24 @rpmfusion-free 342 k
opencv x86_64 2.4.12.3-3.fc24 @anaconda 25 M
opencv-python x86_64 2.4.12.3-3.fc24 @anaconda 1.3 M
pugixml x86_64 1.7-2.fc24 @fedora 232 k
python-nose noarch 1.3.7-7.fc24 @anaconda 1.1 M
python-qt5-rpm-macros noarch 5.6-4.fc24 @updates 137
python2-numpy x86_64 1:1.11.0-4.fc24 @anaconda 15 M
python3-httplib2 noarch 0.9.2-2.fc24 @fedora 291 k
python3-libopenshot x86_64 0.1.1-2.fc24 @rpmfusion-free 1.6 M
python3-qt5 x86_64 5.6-4.fc24 @updates 22 M
python3-qt5-webkit x86_64 5.6-4.fc24 @updates 573 k
python3-sip x86_64 4.18-2.fc24 @updates 457 k
qt5-qtconnectivity x86_64 5.6.1-2.fc24 @updates 1.3 M
qt5-qtenginio x86_64 1:1.6.1-2.fc24 @updates 589 k
qt5-qtmultimedia x86_64 5.6.1-3.fc24 @updates 3.1 M
qt5-qtserialport x86_64 5.6.1-1.fc24 @updates 190 k
qt5-qttools-libs-clucene x86_64 5.6.1-2.fc24 @updates 132 k
qt5-qttools-libs-help x86_64 5.6.1-2.fc24 @updates 647 k
qt5-qtwebsockets x86_64 5.6.1-2.fc24 @updates 230 k
rubberband x86_64 1.8.1-8.fc24 @fedora 879 k
serd x86_64 0.20.0-3.fc24 @fedora 122 k
sord x86_64 0.12.2-8.fc24 @fedora 72 k
sratom x86_64 0.4.6-4.fc24 @fedora 42 k
suil x86_64 0.8.2-4.fc24 @fedora 77 k
theora-tools x86_64 1:1.1.1-14.fc24 @fedora 110 k
uchardet x86_64 0.0.5-4.fc24 @updates 169 k
xorg-x11-server-common x86_64 1.18.3-2.fc24 @anaconda 127 k
xvidcore x86_64 1.3.4-2.fc24 @rpmfusion-free 907 k
youtube-dl noarch 2016.09.15-1.fc24 @updates 6.8 M

Transaction Summary
================================================== ==============================
Remove 78 Packages

Installed size: 234 M

We detect - till now - 2 suspicious packages:

 "xorg-x11-server-common"

&

 "youtube-dl"

I entered in terminal the following:

xorg-x11-server-common --version

But I got this:

bash: xorg-x11-server-common: command not found

Then I open Yum extender (DNF) & searched for "xorg" & got this:

xorg-x11-server-common 1.18.4-4fc24 X86_64 BUT NOT 1.13.3-2 WHICH SHOWN BY "AUTOREMOVE" ! What does this mean ?!

But, I searched for "youtube-dl because I saw it came to me in one of updates. It appear to me in package manager as:

youtube-dl 2016.09.15-1.fc24 noarch & in autoremove list it appear as 2016-09.15-1 ALSO!

In 1st example it seem that no bug but in 2nd example it seem that it is still bugy !!!

Note: both "xorg-x11-server-common" & "youtube-dl" appearing in green color in Yum extender (DNF)

Because this bug is so annoying & dangerous, I decided to post in this closed topic.

(In reply to yousifjkadom from comment #74)
Hi, if you've never used packagekit, then you're not affected by this bug. Removing xorg-x11-server-common doesn't sound right, but it's likely a different problem. Debugging that requires some experience, so either ask for help on forum/irc, or report a separate bug. Thanks.

*** Bug 1376597 has been marked as a duplicate of this bug. ***

I probably encountered this bug with libhif-0.2.3-1.fc25.x86_64 on F25. Should the bug be opened again?

Installation of gnome-builder with Software caused removal of wine, steam and mesa-dri-drivers. The removal of the last package caused the system unable to boot into gdm. I fixed the mess by logging into the text mode console and `sudo dnf install mesa-dri-drivers`.

The actual transaction in /var/lib/PackageKit/transactions.db is:

downloading python3-jedi;0.9.0-5.fc25;noarch;fedora 
downloading devhelp-libs;1:3.22.0-1.fc25;x86_64;fedora 
downloading clang-devel;3.8.1-1.fc25;x86_64;updates 
downloading clang-libs;3.8.1-1.fc25;x86_64;updates 
downloading clang;3.8.1-1.fc25;x86_64;updates 
downloading qt-creator-data;4.1.0-2.fc25.1;noarch;updates 
downloading qt-creator;4.1.0-2.fc25.1;x86_64;updates 
downloading mesa-libxatracker;13.0.4-1.fc25;x86_64;updates 
downloading llvm-libs;3.8.1-2.fc25;i686;updates 
downloading mesa-libOSMesa;13.0.4-1.fc25;i686;updates 
downloading mesa-libOSMesa;13.0.4-1.fc25;x86_64;updates 
downloading mesa-libGLES;13.0.4-1.fc25;x86_64;updates 
downloading mesa-libGL-devel;13.0.4-1.fc25;x86_64;updates 
downloading mesa-libglapi;13.0.4-1.fc25;i686;updates 
downloading mesa-libGL;13.0.4-1.fc25;i686;updates 
downloading mesa-libglapi;13.0.4-1.fc25;x86_64;updates 
downloading mesa-libGL;13.0.4-1.fc25;x86_64;updates 
downloading llvm-libs;3.8.1-2.fc25;x86_64;updates 
downloading llvm;3.8.1-2.fc25;x86_64;updates 
downloading sysprof-cli;3.22.3-1.fc25;x86_64;updates 
downloading libsysprof-ui;3.22.3-1.fc25;x86_64;updates 
downloading gnome-builder;3.22.4-1.fc25;x86_64;updates 
updating llvm-libs;3.8.1-2.fc25;x86_64;updates 
updating mesa-libglapi;13.0.4-1.fc25;x86_64;updates 
updating clang-libs;3.8.1-1.fc25;x86_64;updates 
installing sysprof-cli;3.22.3-1.fc25;x86_64;updates 
installing libsysprof-ui;3.22.3-1.fc25;x86_64;updates 
updating qt-creator-data;4.1.0-2.fc25.1;noarch;updates 
updating qt-creator;4.1.0-2.fc25.1;x86_64;updates 
updating clang;3.8.1-1.fc25;x86_64;updates 
updating mesa-libGL;13.0.4-1.fc25;x86_64;updates 
installing devhelp-libs;1:3.22.0-1.fc25;x86_64;fedora 
installing gnome-builder;3.22.4-1.fc25;x86_64;updates 
updating mesa-libGL-devel;13.0.4-1.fc25;x86_64;updates 
updating clang-devel;3.8.1-1.fc25;x86_64;updates 
updating mesa-libGLES;13.0.4-1.fc25;x86_64;updates 
updating mesa-libOSMesa;13.0.4-1.fc25;x86_64;updates 
updating llvm;3.8.1-2.fc25;x86_64;updates updating 
mesa-libxatracker;13.0.4-1.fc25;x86_64;updates 
installing python3-jedi;0.9.0-5.fc25;noarch;fedora 
updating mesa-libglapi;13.0.4-1.fc25;i686;updates 
updating llvm-libs;3.8.1-2.fc25;i686;updates 
updating mesa-libOSMesa;13.0.4-1.fc25;i686;updates 
updating mesa-libGL;13.0.4-1.fc25;i686;updates 
removing wine;2.7-1.fc25;x86_64;installed 
removing steam;1.0.0.54-9.fc25;i686;installed 
removing mesa-dri-drivers;17.0.5-2.fc25;i686;installed 
cleanup mesa-libOSMesa;17.0.5-2.fc25;x86_64;installed 
cleanup mesa-libGL-devel;17.0.5-2.fc25;x86_64;installed 
cleanup mesa-libGL;17.0.5-2.fc25;x86_64;installed 
cleanup clang-devel;3.9.1-2.fc25;x86_64;installed 
cleanup mesa-libGLES;17.0.5-2.fc25;x86_64;installed 
cleanup clang;3.9.1-2.fc25;x86_64;installed 
removing mesa-dri-drivers;17.0.5-2.fc25;x86_64;installed 
cleanup qt-creator-data;4.1.0-2.fc25.2;noarch;installed 
cleanup qt-creator;4.1.0-2.fc25.2;x86_64;installed 
cleanup clang-libs;3.9.1-2.fc25;x86_64;installed 
cleanup mesa-libxatracker;17.0.5-2.fc25;x86_64;installed 
cleanup llvm;3.9.1-3.fc25;x86_64;installed 
cleanup mesa-libglapi;17.0.5-2.fc25;x86_64;installed 
cleanup llvm-libs;3.9.1-3.fc25;x86_64;installed

Matej, this is most likely a completely different issue. Open up a new bug, probably in gnome bugzilla against gnome-software or packagekit. It seems to be too willing to downgrade packages, for some reason. And attach more information about your system, especially if you have any third-party repos enabled. Those packages you downgraded to are very old. Either it's some third party repo, or some very outdated mirror (and packagekit failed to recognize that it's outdated).

I'm not sure if the PackageKit downgraded the packages. The packages version numbers in the transactions.db are confusing. You can see at the end of the log with "cleanup" prefix the up-to-date versions of the packages (that are now present on my system).

What bothers me most are the removed packages:

removing wine;2.7-1.fc25;x86_64;installed 
removing steam;1.0.0.54-9.fc25;i686;installed 
removing mesa-dri-drivers;17.0.5-2.fc25;i686;installed
removing mesa-dri-drivers;17.0.5-2.fc25;x86_64;installed

Is this not caused by this bug?