[arch-dev-public] [arch-general] [signoff] kernel26 184.108.40.206-1
dale at archlinux.org
Sun Dec 21 08:55:31 EST 2008
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 <redshift at pandora.be> 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.
> 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
220.127.116.11, it's supposed to fix my hibernate regression.
More information about the arch-dev-public