Cleaning /var/lib/dnf/yumdb

[Michael D. Setzer II]

Are files in /var/lib/dnf/yumdb of any use??
Dates of files and directories seem to all be June 20 2019 
and seem to be for Fedora 29 and earlier.
Machine is currently running Fedora 35??

Is there a command to clean them correctly.
Are the just leftovers from pervious versions.
dnf autoremove didn't do anything.

du . shows total size as 42620	.

Was doing a search from files from / and saw a number of 
old files in results.

Thanks.

+------------------------------------------------------------+
 Michael D. Setzer II - Computer Science Instructor 
(Retired)     
 mailto:[e-mail]                            
 mailto:[e-mail]
 Guam - Where America's Day Begins                        
 G4L Disk Imaging Project maintainer 
 http://sourceforge.net/projects/g4l/
+------------------------------------------------------------+

[stan]

On Wed, 29 Jun 2022 21:31:51 +1000
"Michael D. Setzer II via users" <users(a)lists.fedoraproject.org&gt; wrote:

>  Are files in /var/lib/dnf/yumdb of any use??
>  Dates of files and directories seem to all be June 20 2019 
>  and seem to be for Fedora 29 and earlier.
>  Machine is currently running Fedora 35??
>  
>  Is there a command to clean them correctly.
>  Are the just leftovers from pervious versions.
>  dnf autoremove didn't do anything. 
You could run
rpm -qf /var/lib/dnf/[one of the files]
to see if it belongs to any currently installed package. There is a yum
package today, but it just installs a link to dnf.  If you have
dnf-utils installed, you can run 
package-cleanup orphans 
to list packages that are no longer available from current
repositories.  You could then just remove them.  If you don't find any
packages that own those files, you could just remove them manually as
they are outside of package management.

[Michael D. Setzer II]

On 29 Jun 2022 at 6:11, stan via users wrote:

Date sent:      	Wed, 29 Jun 2022 06:11:23 -0700
To:             	users(a)lists.fedoraproject.org
Subject:        	Re: Cleaning /var/lib/dnf/yumdb
Organization:   	zohofree
Send reply to:  	Community support for Fedora 
users <users(a)lists.fedoraproject.org&gt;
From:           	stan via users 
<users(a)lists.fedoraproject.org&gt;
Copies to:      	mikes(a)guam.net, stan 
<upaitag(a)zoho.com&gt;

>  On Wed, 29 Jun 2022 21:31:51 +1000
>  "Michael D. Setzer II via users" <users(a)lists.fedoraproject.org&gt; wrote:
>  
>  > Are files in /var/lib/dnf/yumdb of any use??
>  > Dates of files and directories seem to all be June 20 2019 
>  > and seem to be for Fedora 29 and earlier.
>  > Machine is currently running Fedora 35??
>  > 
>  > Is there a command to clean them correctly.
>  > Are the just leftovers from pervious versions.
>  > dnf autoremove didn't do anything.
>  
>  You could run
>  rpm -qf /var/lib/dnf/[one of the files] 
The directory /var/lib/dnf/yumdb contains
these 
subdirectories?
a  b  c  C  d  e  f  F  g  G  h  i  I  j  k  l  L  m  M  n  N  o  O  p  P  q  r  s  S  t 
T  u  v  V  w  x  y  z

listing the first few in the a subdirectory has these 
subdirectories.
011b42fa971c283946a1a72ca97d253e6c5bbce5-adobe-release-x86_64-1.0-1-noarch
0222420a895a597803ed1249bd18d9ff0fd07c1b-asdcplib-2.10.32-4.fc29-x86_64
034dd931daaafb4e6c77f2fb44c7cdeafc829ac2-apache-commons-chain-1.2-18.fc29-noarch
03b0033cc57f530d2abbe4361785834778f9731f-apache-parent-19-3.fc29-noarch
03dd581fd0266269454cca7e041913ebb4a93e35-apache-ivy-2.4.0-14.fc29-noarch
03f63e2b86c12c7518de6e931062aff6b092b4c5-abrt-gui-libs-2.12.0-2.fc29-x86_64

First one then has these files.
-rw-r--r--.    1 root root    64 Jun  7  2018 checksum_data
-rw-r--r--. 5087 root root     6 Nov  5  2017 checksum_type
-rw-r--r--.   37 root root 70145 Jun  7  2018 command_line
-rw-r--r--.    1 root root    18 Jun  7  2018 from_repo
-rw-r--r--. 3328 root root     4 Jun  7  2018 installed_by
-rw-r--r--. 2650 root root     4 Jun  7  2018 reason
-rw-r--r--.   37 root root     2 Jun  7  2018 releasever

>  to see if it belongs to any currently installed package. There is a
> yum
>  package today, but it just installs a link to dnf.  If you have 
>  dnf-utils installed, you can run 
>  package-cleanup orphans 
installed the dnf-utils
and ran package-cleanup --orphans
it list 297 files on run, but only but only 12 have the fc28 
or fc29?

Was surprised that it listed aespipe as one of files?
aespipe-2.4f-1.fc33.x86_64 is what it shows, so guess it 
isn't included after fc33 for some reason??

Had a number of files from libreoffice 7.3 that were 
listed, but those are not from Fedora repos but installed 
from site. Others don't look like things I manually 
installed so, think there were something that one version 
included and later ones dropped. 

So, question leads to more questions.

Thanks for reply. Was just thinking this was something 
that was left over from earlier versions. Before I retired, I 
would always do an update on one classroom machine 
and do a clean install on another. The would to a rpm -qa 
on both and compare them. Most of the time the majority 
of packages where the same, but usually there were some 
from previous version that were not included in new 
version. Also, usually the new version would have some 
packages that didn't get added in the upgrade process.
Would usually just create a script to add those. 

Thanks again.




>  to list packages that are no longer available from current
>  repositories.  You could then just remove them.  If you don't find any
>  packages that own those files, you could just remove them manually as
>  they are outside of package management.
>  
>  _______________________________________________
>  users mailing list -- users(a)lists.fedoraproject.org
>  To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure


+------------------------------------------------------------+
 Michael D. Setzer II - Computer Science Instructor (Retired)     
 mailto:[e-mail]                            
 mailto:[e-mail]
 Guam - Where America's Day Begins                        
 G4L Disk Imaging Project maintainer 
 http://sourceforge.net/projects/g4l/
+------------------------------------------------------------+

[Barry]

>  On 29 Jun 2022, at 14:12, stan via users
> <users(a)lists.fedoraproject.org&gt; wrote:
>  
>  On Wed, 29 Jun 2022 21:31:51 +1000
>  "Michael D. Setzer II via users" <users(a)lists.fedoraproject.org&gt; wrote:
>  
> > Are files in /var/lib/dnf/yumdb of any use??
> > Dates of files and directories seem to all be June 20 2019 
> > and seem to be for Fedora 29 and earlier.
> > Machine is currently running Fedora 35??
> > 
> > Is there a command to clean them correctly.
> > Are the just leftovers from pervious versions.
> > dnf autoremove didn't do anything.
>  
>  You could run
>  rpm -qf /var/lib/dnf/[one of the files]
>  to see if it belongs to any currently installed package. 
That good advice generally, but I think suspect that yumdb is part of the databases used
to track I stallled software, so that command is unlikely to help.

Barry

>  There is a yum
>  package today, but it just installs a link to dnf.  If you have
>  dnf-utils installed, you can run 
>  package-cleanup orphans 
>  to list packages that are no longer available from current
>  repositories.  You could then just remove them.  If you don't find any
>  packages that own those files, you could just remove them manually as
>  they are outside of package management.
>  
>  _______________________________________________
>  users mailing list -- users(a)lists.fedoraproject.org
>  To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[Michael D. Setzer II]

On 29 Jun 2022 at 18:05, Barry wrote:

Subject:        	Re: Cleaning /var/lib/dnf/yumdb
From:           	Barry <barry(a)barrys-emacs.org&gt;
Date sent:      	Wed, 29 Jun 2022 18:05:17 +0100
To:             	Community support for Fedora users 
<users(a)lists.fedoraproject.org&gt;
Copies to:      	mikes(a)guam.net, stan 
<upaitag(a)zoho.com&gt;
Send reply to:  	Community support for Fedora 
users <users(a)lists.fedoraproject.org&gt;

>  
>  
>  > On 29 Jun 2022, at 14:12, stan via users <users(a)lists.fedoraproject.org&gt;
> wrote:
>  > 
>  > On Wed, 29 Jun 2022 21:31:51 +1000
>  > "Michael D. Setzer II via users" <users(a)lists.fedoraproject.org&gt;
> wrote:
>  > 
>  >> Are files in /var/lib/dnf/yumdb of any use??
>  >> Dates of files and directories seem to all be June 20 2019 
>  >> and seem to be for Fedora 29 and earlier.
>  >> Machine is currently running Fedora 35??
>  >> 
>  >> Is there a command to clean them correctly.
>  >> Are the just leftovers from pervious versions.
>  >> dnf autoremove didn't do anything.
>  > 
>  > You could run
>  > rpm -qf /var/lib/dnf/[one of the files]
>  > to see if it belongs to any currently installed package.
>  
>  That good advice generally, but I think suspect that yumdb is part of the databases used
> to track I stallled software, so that command is unlikely to help.
>  
>  Barry 
Thanks. I have 3 other machines in room that are running 
Fedora 35, and none of them have the /var/lib/dnf/yumdb 
directory at all. Think those were all upgraded with clean 
installs at some point after fedora 30, so think it must be 
something that just got left over thru an upgrade and 
probable should have been removed. 
Think renaming directory for now, and then probable just 
remove it if nothing shows up. Have another old notebook 
that also has fedora 35, but it is not running at moment. 
Will see if it has directory. 
Little concerned that notebook has 5776 packages 
installed and it shows that 276 are orphaned??
Don't know if it means that something caused them to be 
dropped, or if someone just hasn't build a new version of 
them yet? aespipe was the only one that stood out. 

Thanks again.


>  
>  > There is a yum
>  > package today, but it just installs a link to dnf.  If you have
>  > dnf-utils installed, you can run 
>  > package-cleanup orphans 
>  > to list packages that are no longer available from current
>  > repositories.  You could then just remove them.  If you don't find any
>  > packages that own those files, you could just remove them manually as
>  > they are outside of package management.
>  > 
>  > _______________________________________________
>  > users mailing list -- users(a)lists.fedoraproject.org
>  > To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
>  > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  > List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
>  > Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>  _______________________________________________
>  users mailing list -- users(a)lists.fedoraproject.org
>  To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

+------------------------------------------------------------+
 Michael D. Setzer II - Computer Science Instructor 
(Retired)     
 mailto:[e-mail]                            
 mailto:[e-mail]
 Guam - Where America's Day Begins                        
 G4L Disk Imaging Project maintainer 
 http://sourceforge.net/projects/g4l/
+------------------------------------------------------------+

[Andras Simon]

2022-06-29 19:24 UTC+02:00, Michael D. Setzer II via users
<users(a)lists.fedoraproject.org&gt;:

>  Thanks. I have 3 other machines in room that are running
>  Fedora 35, and none of them have the /var/lib/dnf/yumdb
>  directory at all. 
This is strange, because that directory belongs to the dnf-data
package, and I'm sure you have that installed.

[Michael D. Setzer II]

On 29 Jun 2022 at 22:20, Andras Simon wrote:

From:           	Andras Simon <szajmi(a)gmail.com&gt;
Date sent:      	Wed, 29 Jun 2022 22:20:44 +0200
Subject:        	Re: Cleaning /var/lib/dnf/yumdb
To:             	mikes(a)guam.net, 
	Community support for Fedora users 
<users(a)lists.fedoraproject.org&gt;

>  2022-06-29 19:24 UTC+02:00, Michael D. Setzer II via users
>  <users(a)lists.fedoraproject.org&gt;:
>  
>  > Thanks. I have 3 other machines in room that are running
>  > Fedora 35, and none of them have the /var/lib/dnf/yumdb
>  > directory at all.
>  
>  This is strange, because that directory belongs to the dnf-data
>  package, and I'm sure you have that installed. 
Interesting. I did a dnf whatprovides /var/lib/dnf/yumdb 
and it came up with the dnf-data..

It is installed on all 4 machines, but 3 don't have the 
yumdb directory??

Perhaps it is created during the transistion of a system 
that was using yum to dnf, so it is only created at that 
point??

moved the yumdb directory to yumdb.old and then did a 
dnf reinstall dnf-data and it did not create the yumdb 
directory. 

ran the dnf remove dnf-data, and it gives error and 
doesn't list what it would modify.

In /var/lib/dnf/yumdb.old
find . | wc -l
45700

This ended up leaving only subdirectories.

find . | grep -v "fc29\|fc28\|fc27\|fc26" | grep -v "\-15-7" | 
grep -v "keys-29" | grep -v "29-" | grep -v flash-plugin | 
grep -v google-chrome | grep -v adobe-release

Almost all files had fc29 -fc26
find . | grep -v "fc29\|fc28\|fc27\|fc26" | wc -l
137

So must have been created in process of upgrading from 
fc29 to fc30??

Interesting.


+------------------------------------------------------------+
 Michael D. Setzer II - Computer Science Instructor 
(Retired)     
 mailto:[e-mail]                            
 mailto:[e-mail]
 Guam - Where America's Day Begins                        
 G4L Disk Imaging Project maintainer 
 http://sourceforge.net/projects/g4l/
+------------------------------------------------------------+

[Andras Simon]

2022-06-30 0:45 UTC+02:00, Michael D. Setzer II <mikes(a)guam.net&gt;:
>  On 29 Jun 2022 at 22:20, Andras Simon wrote: 
[...]

> > > Thanks. I have 3 other machines in room that are running
> > > Fedora 35, and none of them have the /var/lib/dnf/yumdb
> > > directory at all.
> >
> > This is strange, because that directory belongs to the dnf-data
> > package, and I'm sure you have that installed.
>
>  Interesting. I did a dnf whatprovides /var/lib/dnf/yumdb
>  and it came up with the dnf-data..
>
>  It is installed on all 4 machines, but 3 don't have the
>  yumdb directory??
>
>  Perhaps it is created during the transistion of a system
>  that was using yum to dnf, so it is only created at that
>  point?? 
I don't know, but I'd be surprised if the content of a package
depended on the way the system was installed. Just out of curiosity,
what does
rpm -V dnf-data
say? Does it signal that /var/lib/dnf/yumdb directory is missing?

FWIW I get this:

[simon@localhost ~]$ rpm -V dnf-data
.M.......  g /var/lib/dnf/groups.json
.M.......  g /var/lib/dnf/history
.M.......  g /var/log/hawkey.log

[Michael D. Setzer II]

On 30 Jun 2022 at 15:04, Andras Simon wrote:

From:           	Andras Simon <szajmi(a)gmail.com&gt;
Date sent:      	Thu, 30 Jun 2022 15:04:46 +0200
Subject:        	Re: Cleaning /var/lib/dnf/yumdb
To:             	mikes(a)guam.net
Copies to:      	Community support for Fedora users 
<users(a)lists.fedoraproject.org&gt;
Send reply to:  	Community support for Fedora 
users <users(a)lists.fedoraproject.org&gt;

>  2022-06-30 0:45 UTC+02:00, Michael D. Setzer II
> <mikes(a)guam.net&gt;:
>  > On 29 Jun 2022 at 22:20, Andras Simon wrote:
>  
>  [...]
>  
>  >> > Thanks. I have 3 other machines in room that are running
>  >> > Fedora 35, and none of them have the /var/lib/dnf/yumdb
>  >> > directory at all.
>  >>
>  >> This is strange, because that directory belongs to the dnf-data
>  >> package, and I'm sure you have that installed.
>  >
>  > Interesting. I did a dnf whatprovides /var/lib/dnf/yumdb
>  > and it came up with the dnf-data..
>  >
>  > It is installed on all 4 machines, but 3 don't have the
>  > yumdb directory??
>  >
>  > Perhaps it is created during the transistion of a system
>  > that was using yum to dnf, so it is only created at that
>  > point??
>  
>  I don't know, but I'd be surprised if the content of a package
>  depended on the way the system was installed. Just out of curiosity,
>  what does
>  rpm -V dnf-data
>  say? Does it signal that /var/lib/dnf/yumdb directory is missing?
>  
>  FWIW I get this:
>  
>  [simon@localhost ~]$ rpm -V dnf-data
>  .M.......  g /var/lib/dnf/groups.json
>  .M.......  g /var/lib/dnf/history
>  .M.......  g /var/log/hawkey.log
>  ______________________________ 
I get this.
rpm -V dnf-data
S.5....T.  c /etc/dnf/dnf.conf
.M.......  g /var/lib/dnf/groups.json
.M.......  g /var/log/dnf.librepo.log
.M.......  g /var/log/dnf.log
.M.......  g /var/log/dnf.rpm.log
.M.......  g /var/log/hawkey.log
[root@setzconote ~]# ls /var/lib/dnf/ -l
total 22944
-rw-rw-r--.  1 root root     9677 Nov  5  2017 groups.json
drwxrwxr-x.  3 root root     4096 Jun 20  2019 history.old
-rw-r--r--.  1 root root 18374656 Jun 30 21:58 history.sqlite
-rw-r--r--.  1 root root    32768 Jun 30 21:58 history.sqlite-shm
-rw-r--r--.  1 root root  5038792 Jun 30 16:28 history.sqlite-wal
drwxr-xr-x.  2 root root     4096 May  3  2021 modulefailsafe
drwxr-xr-x. 26 root root     4096 Jun  6 15:44 repos
drwxr-xr-x.  2 root root     4096 Jun  6 17:56 system-upgrade
-rw-r--r--.  1 root root     1878 Dec  2  2020 system-upgrade.json
drwxr-xr-x. 40 root root     4096 Jun  7  2018 yumdb.old

I renamed the yumdb subdirectory to yumdb.old
and subdirectory history to history.old

history.old has 
drwxrwxr-x. 382 root root     12288 Jun 19  2019 2017-11-05
-rw-------.   1 root root 247648256 Jun 20  2019 history-2017-11-05.sqlite

The subdirectory 2017-11-05 has a ton of numbered 
subdirectores with tiny config-main and config-repo 
files??

_________________
>  users mailing list -- users(a)lists.fedoraproject.org
>  To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure


+------------------------------------------------------------+
 Michael D. Setzer II - Computer Science Instructor (Retired)     
 mailto:[e-mail]                            
 mailto:[e-mail]
 Guam - Where America's Day Begins                        
 G4L Disk Imaging Project maintainer 
 http://sourceforge.net/projects/g4l/
+------------------------------------------------------------+

[Jonathan Billings]

On Jun 29, 2022, at 18:46, Michael D. Setzer II via users
<users(a)lists.fedoraproject.org&gt; wrote:
>  
>  It is installed on all 4 machines, but 3 don't have the 
>  yumdb directory?? 
The RPM spec file for dnf shows that it does own the yumdb directory in the dnf package,
but it has the %ghost attribute, which means that it doesn’t actually include the actual
files in the package.  

https://src.fedoraproject.org/rpms/dnf/blob/f36/f/dnf.spec#_300

This is done to make the RPM database know that it’s technically part of the package, but
not to actually include any files in the package distribution.  Usually this is because
they’re user generated and ephemeral, like what is happening here.

I suspect this is left over from some Fedora system upgrade and no longer used. I don’t
have a device handy to look at the source to see why the %ghost attribute was added, but I
suspect you can just delete it and it’ll operate fine.  At least make a tarball of it and
try removing it to see if it is ok without it.

-- 
Jonathan Billings