Question to show-installed

Florian Festi ffesti at redhat.com
Tue Mar 17 10:45:50 UTC 2015


On 03/16/2015 04:18 PM, Radek Holy wrote:
> 
> 
> ----- Original Message -----
>> From: "Florian Festi" <ffesti at redhat.com>
>> To: yum-devel at lists.baseurl.org
>> Sent: Friday, March 13, 2015 10:55:58 AM
>> Subject: Re: Question to show-installed
>>
>> On 03/12/2015 11:10 AM, Radek Holy wrote:
>>> Take a look at `dnf history userinstalled`. I think this is actually what
>>> you are looking for. The output is designed so that it can be directly
>>> used in the Kickstart files. The disadvantage is that DNF does not share
>>> the history database with YUM. Thus the command works only for packages
>>> installed via DNF. If a package is not installed via DNF, the command
>>> assumes that the package is not "installed by a user".
>>
>> With the yum/dnf history being messed up the way it is I wonder if this
>> command should actually do what show-installed does in addition to
>> looking into the history. Ending up with a kickstart list that is
>> missing important parts of the system is of very little help.
>>
>> This is IMHO one example where we just do not give the user the
>> information she needs although we actually know that data we provide is
>> lacking.
> 
> Actually, I confused "YUM/DNF history" with "YUMDB/DNFDB". DNF would need *YUMDB* to work with packages installed by YUM. But the rest is correct.
> 
> Hm, if you could tell me what does "show-installed" do, I could tell you whether it is what `dnf history userinstalled` should do. Man pages say "gives a compact description of the packages installed (or given) making use of the comps groups found in the repositories". This is very vague. I can talk about "dnf info installed" and "dnf group" but I know that "show-installed" does something else.

Well, show-installed tries to construct a minimal list of groups and
packages that can go into a kickstart file to reconstruct the current
set of packages. I implemented it basically as a prove of concept
implementation that I had hoped would be picked up to close the gaps we
have in the userinstalled data in the yum/dnf db/history. Unfortunately
this never happened.

> But I guess that the answer is: "no". Actually, the purpose of `dnf history userinstalled` is very simple. It should do what was requested in a bug 884615.

The problem is that the definition of "simple" is the wrong one. It is
"simple" in the sense of "easy to get from the data we have". IMHO we
should focus more an making answers to the simple questions that users
would ask available. The question that comes to mind is "What got
installed on this system?" dnf history userinstalled asks this question
but restricts the answer to "but only after the system got installed"
which is a restriction, making the question more complicated - much less
useful - but more easy to answer.

What we'd need is a yum list command that returns a (kickstart
compatible) list of groups and packages that will get the system in the
same state as it is right now - including the yumdb metadata. So all
packages and groups that were tagged with reason "user" would still be
in the reinstalled system (some packages might be additionally)[*].

The reason why this is an interesting command to have is not only the
user in kickstart but much more that it gives a compact, human readable
description of the whole system.

This would of course need to be based on the userinstalled data but with
additional reasoning for the leaf packages that - for what ever reason -
are not tagged as userinstalled.

Florian

[*] I guess this won't work because anaconda won't tag the packages
properly but this does not disprove my point. In opposite it is (if it
is in fact true) just one more place where this whole "reason" thing is
not thought through/not properly implemented.

-- 

Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Charles Peters


More information about the Yum-devel mailing list