Red Hat Bugzilla – Bug 203329
/etc/readahead.files include old file names
Last modified: 2007-11-30 17:11:40 EST
Description of problem:
Even though Firefox is updated to 184.108.40.206 by yum,
/etc/readahead.files still points firefox 220.127.116.11.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install FC5
2. Update to latest RPMs (as of 21/Aug,2006)
3. Confirm the system has firefox 18.104.22.168
4. # grep firefox /etc/readahead.files
The directory name is still older version.
/etc/readahead.files should contain latest directory name and file name.
How can we update the /etc/readahead.files up to date?
Update list by some script?
Each RPM provide filename list?
Can we have an /etc/readahead.custom and /etc/readahead_early.custom
for user's custom readahead setting purpose?
You can create /etc/readahead.d/foo.early and foo.later in FC6. The list of
files should be also more up to date now.
Sorry this isnt good enough....
As packages get updated in fc6 the readahead files are not being updated
accordingly. Right now for example the firefox listings in fc6's readahead is
out of sync with the latest firefox update package libraries.
What we need is a mechanism that we can update these listing on a per package
update basis. You aren't going to be able to keep up with this unless
individual package maintainers have the ability to modify the readahead listings
for their own packages. Off the top of my head I see two options.
1)move to a readahead.d directory structure and let individual packages drop
configs so each package maintainer can ensure syncage.
2)make a set of rpm scriptlet utilities to modify these files that can be called
by individual packages.
I'd dont want to see a continual respin of readhead packages just so that it can
gou out of sync again in a couple of days. That's unncessary update package
churn for nearly no benefit for end-users. Let's generally readahead
configuration management enough so individual package updates can make use of
this functionality without re-configuration lag.
sorry... i misunderstood.
we do have the .d/ structure.... we just need to get individual package
maintainers to start dropping files in there. I guess i can close this again.
The problem is not at readhead... but at the next level... getting the
individual maintainers to drop files in to readahead.d/
*** Bug 227289 has been marked as a duplicate of this bug. ***
There is a way how keep the lists up to date:
Use "init=/sbin/readahead-collector", closing. The default lists will be updated
manually always at Final Development Freeze.