Bug 144712 - rpm -V kernel fails
Summary: rpm -V kernel fails
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: rpm
Version: 4.0
Hardware: ia64
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Jeff Johnson
QA Contact: Mike McLean
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-01-10 21:41 UTC by Richard Li
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-01-14 17:35:47 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

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) 


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