On Sun, 2008-12-21 at 09:48 +0100, Tobias Powalowski wrote: > Am Dienstag 16 Dezember 2008 schrieb Jan de Groot: > > On Mon, 2008-12-15 at 14:42 -0600, Aaron Griffin wrote: > > > On Mon, Dec 15, 2008 at 2:41 PM, RedShift <[email protected]> wrote: > > > > Why not solve it the right way, by creating a correct package? > > > > > > I think you're missing why this is impossible. Anyone that has m-i-t > > > 3.5 on their system now has the .bin files that are owned by no > > > package. pacman correctly does not overwrite these files. > > > > > > What "correct package" are you suggesting? > > > > As these files are generated by module-init-tools whenever it is run for > > your kernel, why not solve this using post_* functions? > > Whenever the kernel gets installed/upgraded, depmod is run from > > post_install/upgrade. Whenever the kernel is removed, the files created > > by depmod for this kernel get removed from post_remove. Shouldn't be > > hard to do, the result is the same and no file conflicts will exist. > Well depmod is already called in .install file. > Why to make a remove in PKGBUILD and create untraced files on the system? > This bug affects only people who run testing and installed new external > modules. This should be not a big part of the community, mostly noone runs > testing ;) > > > BTW: Please remove the -v flag from depmod in kernel26.install, it's > > stupid to make depmod print verbose messages while redirecting output > > to /dev/null. > fixed > > Before releasing .10 kernel I would like to have a clear answer on how to > handle this. > My suggestion would be the --force option, the other thing is a workaround > which is imho not needed here.
If someone runs testing, they better be able to figure out "pacman -Sf kernel26", especially if we make posts about it. I'm anxious for 2.6.27.10, it's supposed to fix my hibernate regression. Dale
