Bug 505280 - package-cleanup --cleandupes doesn't work correctly
package-cleanup --cleandupes doesn't work correctly
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: yum-utils (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Seth Vidal
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-11 06:33 EDT by Gerhard Wiesinger
Modified: 2014-01-21 18:09 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-10-12 12:00:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Gerhard Wiesinger 2009-06-11 06:33:20 EDT
Description of problem:
After update from Fedora 10 to Fedora 11 (even from previous versions) old packages still exist.

E.g.:
ant-javadoc-1.7.1-7.2.fc10.x86_64
ant-javadoc-1.7.1-9.2.fc11.x86_64

antlr-manual-2.7.7-2.fc10.x86_64
antlr-manual-2.7.7-5.fc11.x86_64

bash-3.2-30.fc10.x86_64
bash-4.0-6.fc11.x86_64

binutils-2.18.50.0.9-8.fc10.x86_64
binutils-2.19.51.0.2-17.fc11.x86_64

package-cleanup --cleandupes
Removed some of the dupes but not all. Still the above are there

Version-Release number of selected component (if applicable):
anaconda-yum-plugins-1.0-4.fc11.noarch
PackageKit-yum-0.4.6-8.fc11.x86_64
PackageKit-yum-plugin-0.4.6-8.fc11.x86_64
yum-3.2.22-4.fc11.noarch
yum-metadata-parser-1.1.2-12.fc11.x86_64
yum-utils-1.1.21-2.fc11.noarch

How reproducible:
rpm -qa --queryformat "%{NAME};%{VERSION};%{RELEASE};%{ARCH}\n" | ~/bin/rpm_show_duplicate_packages.pl
cat ~/bin/rpm_show_duplicate_packages.pl
#!/usr/bin/perl

# rpm -qa --queryformat "%{NAME};%{VERSION};%{RELEASE};%{ARCH}\n" | ~/bin/rpm_show_duplicate_packages.pl
# Nearly default format (except some ".(none)" architectures)
# rpm -qa --queryformat "%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n"

my %packagename = ();

while (<STDIN>)
{
  chomp;
  my ($name, $version, $release, $arch) = split(';');
  my $fullname = $name . "-" . $version . "-" . $release . "." . $arch;

  if (exists $packagename{$name})
  {
    my @list = @{$packagename{$name}};
    push(@list, $fullname);
    $packagename{$name} = \@list;
  }
  else
  {
    # http://lists.evolt.org/archive/Week-of-Mon-19990906/089840.html
    my @list = ($fullname);
    $packagename{$name} = \@list;
  }
}

for my $name (sort keys %packagename)
{
  my @list = @{$packagename{$name}};
  my $listlen = @list;
  if ($listlen > 1)
  {
    foreach (@list)
    {
      print $_, "\n";
    }
  }
}

Steps to Reproduce:
1.
2.
3.
  
Actual results:
Old packages are still there

Expected results:
No old packages there

Additional info:
Comment 1 Michael Schwendt 2009-06-11 06:52:53 EDT
* Yum (or RPM to be accurate) didn't remove the old packages, because your transaction which you had started from Yum Shell was interrupted with a fatal exception. Mind you, it didn't find the additional packages in $pwd, and yum-complete-transaction couldn't continue either.

* Does "package-cleanup --dupes" list the remaining duplicates?
If it does, what do you get for
"rpm --erase --justdb --noscripts ant-javadoc-1.7.1-7.2.fc10.x86_64"?
Comment 2 Gerhard Wiesinger 2009-06-11 07:10:59 EDT
* Ad1) Yes, that's true. As discussed privately transaction has been aborted.

But as far as I remember I've seen the behavior on correct updates that there were some dupes left. (Although I don't have hard facts for that issue).

* Ad2)
package-cleanup --dupes
=> No package output
Comment 3 Michael Schwendt 2009-06-11 07:48:29 EDT
Then it's obvious that it doesn't remove any. :)  If after

  rm -f /var/lib/rpm/__db.*
  rpm -vv --rebuilddb

nothing changes, a closer look at how package-cleanup finds dupes will be needed. Independently, you could still clean them yourself as in the example in comment 1.
Comment 4 Gerhard Wiesinger 2009-06-11 09:58:30 EDT
After rebuild of the rpm database, it finds some more packages (58), but still not all. Seems the yum algorithms is broken.

It thing the --justdb leaves garbage:
"rpm --erase --justdb --noscripts ant-javadoc-1.7.1-7.2.fc10.x86_64"?  

e.g.
rpm -ql bash-3.2-30.fc10.x86_64 > file1.txt
rpm -ql bash-4.0-6.fc11.x86_64 > file2.txt
diff -u file1.txt file2.txt

=> There is a difference => garbage would be left open.
Comment 5 Michael Schwendt 2009-06-11 10:33:45 EDT
--justdb is not mandatory. e.g. erasing the older bash pkg doesn't remove files which also belong into the new bash pkg
Comment 6 Kev 'Kyrian' Green 2009-07-31 18:17:52 EDT
Having just been through a nightmare, I think this system should also detect duplicate packages with different architectures.

After having had FC11 fail to recognise insertion of a CD, I tried upgrading, that failed, and downgrading the relevant packages failed too.

Thereafter realising my system had a 64-bit chip, but for various reasons (most notably lack of a 64-bit flash plugin) was still running 32-bit Fedora, I tried swapping it to x86_64 architecture.

The installer seemed to insist I wipe my partitions and start again (a sensible approach, I agree, but not one I could stomach at the time), but it left me no way to clear duplicate packages, or swap packages from one architecture to another, as "rpm -Fvh" would not 'freshen' packages to a different architecture (even if it's the current one and the old package is not!) and indeed yum would do the same, I was forced to do this manually, and using "rpm -Uvh" or similar, thus resulting in lots of duplicate packages with different architectures and no realistic way apart from package-cleanup to sort it out.

package-cleanup, obviously, did not help, so it would be good if it could, please.
Comment 7 seth vidal 2009-10-12 12:00:21 EDT
committed a patch upstream to package-cleanup to add a --noscripts option for --cleandupes that will remove older duplicates w/o running the scriptlets.

this should solve the above problem.

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