Bug 528383
Summary: | "rpm -V" should report missing files once replacing package is erased | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Matt McCutchen <matt> |
Component: | rpm | Assignee: | Panu Matilainen <pmatilai> |
Status: | CLOSED UPSTREAM | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 13 | CC: | ffesti, jnovy, n3npq, pmatilai |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2011-03-09 08:50:45 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Matt McCutchen
2009-10-11 19:14:51 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). (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. 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. (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. (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. (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.) 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. 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. (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. 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. 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 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. |