Bug 1284194 - dnf history userinstalled lists too many/not all user-installed packages
dnf history userinstalled lists too many/not all user-installed packages
Status: CLOSED DUPLICATE of bug 1259865
Product: Fedora
Classification: Fedora
Component: dnf (Show other bugs)
23
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: packaging-team-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-21 15:22 EST by Georg Sauthoff
Modified: 2015-12-31 01:10 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-11-23 08:17:16 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Georg Sauthoff 2015-11-21 15:22:05 EST
Description of problem:

The command

    dnf history userinstalled

lists some packages that were not installed by a user.

Also, it omits some packages that were installed by a user.


Version-Release number of selected component (if applicable):


How reproducible:
always

Steps to Reproduce:

1. Install Fedora 23.
2. Install some packages via `dnf install`
3. Install some packages via typing a missing command and waiting for the not-found-but-do-you-want-to-install prompt; type 'y'
4. Call `dnf history userinstalled` and verify that all user-installed packages are there and that no extra packages are listed

## Example of a package that wasn't installed by a user

Actual results:

# dnf history userinstalled |grep grub2                                    
grub2

Although:

for i in $(seq 16); do echo "Transaction: $i"; dnf history info $i | grep 'User\|grub'; done
Transaction: 1
User           : System <unset>
    Install grub2-1:2.02-0.23.fc23.x86_64                                      @fedora

Meaning that grub2 was actually installed by anaconda. As part of the default install. And not explicitly by the user via e.g. `dnf install`.

Expected results:

# dnf history userinstalled | grep grub2
# echo 'i.e. grub2 is not listed'

## Example of a missing package

Actual results:

# dnf history userinstalled |  grep 'ncurses-devel'
# echo 'i.e. no matches'

Although:

# for i in $(seq 16); do echo "Transaction: $i"; dnf history info $i | grep 'User\|ncurses-devel'; done
Transaction: 5
User           :  <gms>
    Install ncurses-devel-5.9-21.20150214.fc23.x86_64                                       @fedora

# rpm -ql ncurses-devel
[..listing of all the files..]

Expected results:

# dnf history userinstalled |  grep 'ncurses-devel'
ncurses-devel



Similar story for package 'postgresql' where `dnf history userinstalled` only lists:

postgresql-contrib
postgresql-devel
postgresql-docs
postgresql-server
postgresql-upgrade
qt-postgresql


Although the `dnf install` command explicitly included these package in that list (in that order):

postgresql
postgresql-contrib
postgresql-devel
postgresql-docs
postgresql-server
postgresql-upgrade
qt-postgresql



## Example of missing packages that were automatically installed 

(i.e. via the command-not-found-handler)

Actual results:

# dnf history userinstalled |  grep '\(hdparm\|vim$\|screen\)'
# echo 'i.e. no matches'

It seems that the install actions by the command-not-found-handler are not recorded in the dnf history:

# for i in $(seq 16); do echo "Transaction: $i"; dnf history info $i | grep 'User\|hdparm'; done
# echo 'i.e. no line matches hdparm'

Expected results:

# dnf history userinstalled |  grep '\(hdparm\|vim$\|screen\)'
hdparm
vim-enhanced
screen

## Example of missing package because it was obsoleted

Actual results:

# dnf history userinstalled | grep ardour
# echo 'i.e. no line matches'

Although:

# for i in $(seq 16); do echo "Transaction: $i"; dnf history info $i | grep 'User\|ardour'; done
Transaction: 5
User           :  <juser>
    Install ardour-2.8.16-15.fc23.x86_64                                                    @fedora
Transaction: 6
User           :  <juser>
Transaction: 7
User           :  <juser>
    Obsoleted  ardour-2.8.16-15.fc23.x86_64                                    @fedora
    Obsoleting ardour2-2.8.16-17.fc23.x86_64                                   @fedora
    Install    ardour2-2.8.16-17.fc23.x86_64                                   @fedora

Meaning that the package 'ardour' indeed was installed by a user, but as part of a `dnf update` it was obsoleted by the package `ardour2`. Thus, the obsoleting package should inherit the 'userinstalled' attribute. Otherwise, ardour would be lost when the output of `dnf history userinstalled` is used in a kickstart file.

Expected results:

# dnf history userinstalled | grep ardour
ardour2


Additional info:

Another related thing:

It would be great to have a way to mark already installed packages (that were installed as dependency or by anaconda) as userinstalled.

For example when I execute:

# dnf install unoconv
Last metadata expiration check performed 2:39:46 ago on Sat Nov 21 18:07:58 2015.
Package unoconv-0.7-1.fc23.noarch is already installed, skipping.

I get this message because the package is indeed included in the default package selection, and thus was installed by anaconda.

But it would be nice if that install command would still add the 'userinstalled' attribute.

Advantage: When using the output of `dnf history userinstalled` to install packages on another Fedora system I would be sure I get all the packages I care about - even if the other system was installed as minimal - or even if it was a future Fedora version were certain packages are not part of the default package selection anymore.

(IIRC, `apt-get install` does change the marking of the specified packages to user-installed)
Comment 1 Georg Sauthoff 2015-11-21 15:28:30 EST
I found a way to manipulate the 'userinstalled' flag, the `dnf mark` command.

For example:

    # dnf mark install unoconv

Perhaps it is better to have that feature in a separate command.
Comment 2 Georg Sauthoff 2015-11-21 15:44:54 EST
Details on the command-not-found handler:

In my shell it is called from the shell functions `command_not_found_handler()` and `command_not_found_handle()`.

The function `command_not_found_handle()` basically calls /usr/libexec/pk-command-not-found which is part of the PackageKit-command-not-found package.


Thus, for easier reproduction one can directly call it like this:

Actual results:

# echo 'make sure that package nano is indeed not installed'
# /usr/libexec/pk-command-not-found nano
# echo '<- enter Y'
# dnf history userinstalled | grep nano
# echo 'i.e. lists nothing'

Expected results:

# echo 'make sure that package nano is indeed not installed'
# /usr/libexec/pk-command-not-found nano
# echo '<- enter Y'
# dnf history userinstalled | grep nano
nano
Comment 3 Michal Luscon 2015-11-23 08:17:16 EST

*** This bug has been marked as a duplicate of bug 1259865 ***

Note You need to log in before you can comment on or make changes to this bug.