Bug 144712

Summary: rpm -V kernel fails
Product: Red Hat Enterprise Linux 4 Reporter: Richard Li <richardl>
Component: rpmAssignee: Jeff Johnson <jbj>
Status: CLOSED WONTFIX QA Contact: Mike McLean <mikem>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.0CC: nobody+pnasrat
Target Milestone: ---   
Target Release: ---   
Hardware: ia64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-01-14 17:35:47 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 Richard Li 2005-01-10 21:41:42 UTC 
Description of problem:

rpm -V kernel fails on ia64, possibly because vfat doesn't do permissions.

How reproducible:

Always.

Steps to Reproduce:
1. rpm -V kernel

Actual results:

a couple lines that include /boot/efi ...

Expected results:

The prompt.

Additional info:

I'm filing under RPM because possible solution is for RPM to not verify perms on
vfat, but I'm not the expert here...
Comment 1 Jeff Johnson 2005-01-11 04:08:08 UTC 
Probably true. VFAT is so weird ...
Comment 2 Jeff Johnson 2005-01-14 17:35:47 UTC 
There are several approaches to working around --verify failures
on file systems that do no supply the basic elements that
are verified.

1) Live with false positives with existing --evrify.
   False positives with known implementation deficiencies
   (like VFAT does not have group/other permissions) has
   the benefit of indicating to the user that the intended
   check is failing.

2) Create false negatives by making --verify aware of VFAT deficiencies.
   False negatives are a lie, and teaching rpm about file system
   deficiencies is non-trivial, particularly with selinux file      
   contexts, and require users to understand a more complicated
   --verify mechanism.

3) Add a '?' dunno state.
   Again, the '?' indicator has usually created more questions
   than answers, as what users *really* want is not to be bothered.

I believe that the existing false positive scheme is as good
as any other solution, hence WONTFIX. Get this bug attached to
some tracker bug instead of arguing with me please.

3)