Bug 528383 - "rpm -V" should report missing files once replacing package is erased
Summary: "rpm -V" should report missing files once replacing package is erased
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: 13
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Panu Matilainen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-10-11 19:14 UTC by Matt McCutchen
Modified: 2011-03-09 08:50 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-03-09 08:50:45 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Matt McCutchen 2009-10-11 19:14:51 UTC
Description of problem:
I noticed that after installing i?86 and x86_64 versions of a package and then removing the x86_64 version, the executables were missing.  That's understandable: rpm removed the x86_64 executables and had no way to magically bring back the i?86 ones.  But I think "rpm -V" on the i?86 package should then report the missing executables, since they are likely to break the functionality of the package.  More generally, a replaced file should be reported as missing if the package that replaced it is no longer present.

This looks related to bug 171279.

Version-Release number of selected component (if applicable):
rpm-4.7.1-1.fc11.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Set up a little chroot containing /etc/rpm/platform set to x86_64-redhat-linux and the fedora-release-11-1.noarch package.
2. yum --installroot=/PATH/TO/root install openssl.i686 openssl.x86_64
3. rpm --root=/PATH/TO/root -e openssl.x86_64
4. ls -l /PATH/TO/root/usr/bin/openssl
5. rpm --root=/PATH/TO/root -V openssl.i686

Actual results:
Lots of ".......T." for the reason discussed in bug 171279, but nothing about /usr/bin/openssl .

Expected results:
missing      /usr/bin/openssl

Comment 1 Jeff Johnson 2009-10-17 03:10:10 UTC
When x86_64 executables replace i386 executables, the
i386 executable is marked "replaced" rather than "normal".

The file state can be displayed with "rpm -qs pkg" (which is essentially
what you are asking for, a way to detect files that are not installed
and so the package may not function).

The "missing" from --verify is the specific condition of a "normal" file
that is not present on the file system.

There are other not installed conditions, not just "replaced", that cannot
be bundled into a --verify "missing" category for an all purpose spewage.

The real flaw is that rpm should undertake restoring the i386 executables
when removing a x86_64 package. But that gonna happen soon (if ever).

Comment 2 Matt McCutchen 2009-10-18 03:25:23 UTC
(In reply to comment #1)
> When x86_64 executables replace i386 executables, the
> i386 executable is marked "replaced" rather than "normal".
> 
> The file state can be displayed with "rpm -qs pkg" [...]

> The "missing" from --verify is the specific condition of a "normal" file
> that is not present on the file system.

I figured out as much.

> (which is essentially
> what you are asking for, a way to detect files that are not installed
> and so the package may not function).

Not quite.  RPM's presumption is that replacing a file from package A with a "better" file from package B will not break package A, so I don't want to detect a replaced file as long as a better file is installed in its place.  But if the better file goes missing, that will probably break package A, so what I really want is that verification of a replaced file should verify the replacing file instead.

I see in the man page that --verify is limited to "installed" files, but it's common perception that --verify is the way to determine whether a package is broken, and the support for verify scriptlets to perform custom checks reinforces this idea.  So I think it would be reasonable to amend the spec of --verify in this case.  If you don't, I would still like to see the functionality in a separate option.

Comment 3 Jeff Johnson 2009-10-18 04:16:54 UTC
One can already fiddle up the logic with --verify to filter the
output to meet opinions of common perceptions and luser
expectations. One can already do that in packaging, or with
disablers from the CLI, and it wouldn't be more than 2-4 lines
of code to also make --verify output configuration persistent.

Detecting a replaced and then removed file is no harder than
coupling a state transition back to "normal" when the package
of the other arch is removed, thereby inverting the transition
that occurred when one of the packages was installed.

But again, the real flaw is that having two different contents
on the same path is confusing to everyone. And the real
solution needs to be to copy the right executable back into
place from persistent storage.

Telling a luser that a file is "missing" solves no issue that isn't
better solved by putting the content in place. Which is what
I'm implementing, just not in the version of RPM that you are using.

Comment 4 Matt McCutchen 2009-10-18 04:31:18 UTC
(In reply to comment #3)
> One can already fiddle up the logic with --verify to filter the
> output to meet opinions of common perceptions and luser
> expectations. One can already do that in packaging, or with
> disablers from the CLI, and it wouldn't be more than 2-4 lines
> of code to also make --verify output configuration persistent.
> 
> Detecting a replaced and then removed file is no harder than
> coupling a state transition back to "normal" when the package
> of the other arch is removed, thereby inverting the transition
> that occurred when one of the packages was installed.

> Telling a luser that a file is "missing" solves no issue that isn't
> better solved by putting the content in place.

True.  I only suggested reporting the file as missing because I thought that would be easier to implement.

> Which is what
> I'm implementing, just not in the version of RPM that you are using.  

Ah, I see.  Then this bug can remain open for Fedora to implement one of the two approaches you described, whether by adopting said RPM version or otherwise.

Comment 5 Matt McCutchen 2009-10-18 04:33:35 UTC
(In reply to comment #3)
> One can already fiddle up the logic with --verify to filter the
> output to meet opinions of common perceptions and luser
> expectations. One can already do that in packaging, or with
> disablers from the CLI, and it wouldn't be more than 2-4 lines
> of code to also make --verify output configuration persistent.
> 
> Detecting a replaced and then removed file is no harder than
> coupling a state transition back to "normal" when the package
> of the other arch is removed, thereby inverting the transition
> that occurred when one of the packages was installed.

This isn't quite enough: if a 32-bit executable is replaced and then the 64-bit one gets damaged, I want to see that when verifying the 32-bit package.

Comment 6 Matt McCutchen 2009-10-18 04:39:06 UTC
(In reply to comment #3)
> But again, the real flaw is that having two different contents
> on the same path is confusing to everyone. And the real
> solution needs to be to copy the right executable back into
> place from persistent storage.

Or, how about not having two different contents at the same path in the first place?  IMHO, RPM's color support is a nasty hack and the packagers should really have renamed the executables or split them into subpackages.

(I regret the multiple bugmails in rapid succession.  Apparently I think a little bit at a time.)

Comment 7 Jeff Johnson 2009-10-18 04:53:50 UTC
Multilib was not designed by me, the RPM implementation was
done entirely to management request at the time.

I personally think multilib is badly flawed, and the only serious
advantage of the existing multilib implementation is that all the
other alternatives, like FAT executables, are far worse.

Expecting verification of a elf32 package to detect damaged elf64
content just doesn't make any sense at all. For starters, the digests
of the elf64 file content plain and simply are not present in the elf32
package.

Comment 8 Jeff Johnson 2009-10-18 04:58:13 UTC
I think RPM colors are a nasty hack. But I'm just the
guy who was asked to do the implementation at
the time.
'Twas a job mon. I proposed, and implemented
a prototype, and demonstrated functionality.

Blaming RPM for colors kinda misses other
facts, such as that RedHat is a business, and
made money by delivering solutions to paying
customers.

Comment 9 Matt McCutchen 2009-10-18 05:22:32 UTC
(In reply to comment #7)
> Expecting verification of a elf32 package to detect damaged elf64
> content just doesn't make any sense at all.

Not flagging the elf32 content as replaced is based on the presumption that the elf64 content is better.  If the elf64 content is damaged, that presumption doesn't hold.  It's a stretch, but I think it's what users would want.

> For starters, the digests
> of the elf64 file content plain and simply are not present in the elf32
> package.  

They're in the RPM database keyed to the path in question.

Comment 10 Jeff Johnson 2009-10-18 05:30:28 UTC
Do you _REALLY_ expect
    rpm -V foo.i386
to identify damaged x86_64 content simply because
the digests are available in an rpmdb?

You can of course expect anything you wish. And there's
nothing whatsoever stopping you from changing RPM
--verify to behave _EAXCTLY_ as you and you alone expect.

Comment 11 Bug Zapper 2010-04-28 10:47:38 UTC
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 12 Panu Matilainen 2011-03-09 08:50:45 UTC
This is now fixed upstream to some extent:

File status is taken into account when checking dependencies so that a package whose files have been replaced by another package no longer satisfies dependencies for the replaced files. This prevents breaking direct dependencies on such files, eg:

[root@localhost rpm]# rpm -qf /usr/bin/xmlcatalog
libxml2-2.7.7-2.fc14.x86_64
libxml2-2.7.7-2.fc14.i686
[root@localhost rpm]# rpm -qs libxml2|grep /usr/bin/xmlcatalog
normal        /usr/bin/xmlcatalog
wrong color   /usr/bin/xmlcatalog
[root@localhost rpm]# rpm -q --whatrequires /usr/bin/xmlcatalog
xhtml1-dtds-1.0-20020801.5.noarch
docbook-dtds-1.0-53.fc14.noarch

This is the former behavior:
[root@localhost rpm]# rpm -e --test libxml2-2.7.7-2.fc14.x86_64 2>&1|grep /usr/bin/xmlcatalog
[root@localhost rpm]#

And now:
[root@localhost rpm]# ./rpm -e --test libxml2-2.7.7-2.fc14.x86_64 2>&1|grep /usr/bin/xmlcatalog
	/usr/bin/xmlcatalog is needed by (installed) xhtml1-dtds-1.0-20020801.5.noarch
	/usr/bin/xmlcatalog is needed by (installed) docbook-dtds-1.0-53.fc14.noarch
[root@localhost rpm]#

Also verify now notices if replaced or wrong colored files have gone completely missing from the system (in this case there are no dependencies to prevent removal):
[root@localhost rpm]# rpm -Uvh /tmp/hwloc-1.1-0.1.fc14.*
Preparing...                ########################################### [100%]
   1:hwloc                  ########################################### [ 50%]
   2:hwloc                  ########################################### [100%]
[root@localhost rpm]# rpm -qls hwloc|grep /usr/bin/hwloc-bind
normal        /usr/bin/hwloc-bind
wrong color   /usr/bin/hwloc-bind
[root@localhost rpm]# rpm -e hwloc.x86_64

This is the former behavior:
[root@localhost rpm]# rpm -V hwloc
[root@localhost rpm]#

And now:
[root@localhost rpm]# ./rpm -V hwloc|grep /usr/bin/hwloc-bind
missing     /usr/bin/hwloc-bind
[root@localhost rpm]#

There are still improvements to be made but it's a start... Not going to get fixed for F13 at this point but it'll end up in Fedora through updates to later versions sooner or later.


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